Все верно. Для этого все и разделяется по уровням. Инженеры читают одни книжки — им свои цели описываем. шефы — иные книжки наверное читают, что не факт. Ну им иначе пишем. Вместо одного огромного документа пишем 7 малых, каждый для своего уровня. Кстати, если никто и ничего не читал. То сначала делаем стандарты организации (СТО) для всех процессов. Это несложно, если базировать их на готовых стандартах, а не придумывать самим. Тогда получаем стандарт процесса 3-5 страниц, включая обложку. Коротко, просто, практично можно в виде комиксов или картинок, схем. На картинке только один аспект, только 5-9 элементов, только очень короткая часть процесса. И опять же, по аддитивной логике. И по типовым шаблонам. Пример из жизни: сделали систему управления качеством для фирмы, которая производит полимербетон. Все СТО, плюс таблицы и отчеты за год работы собрали в одну систему. В сумме около 100 отчетов и 15-17 СТО. С анализом, обоснованием и т.п. Использовали G Suite, плюс надстройки для схем и планирования. Делали 2 человека, в сумме около 80 нормочасов на всю. работу.
Благо дарю за ответ!
Уже пишу статьи. Будет не одна, а скорее всего много. Материл есть, надо причесать и некоторые части перевести с польского и английского.
Извините, совсем забыл.
Цели у Вас msin указаны и сформулированы совершенно правильно!
Просто Вы используете одну методологи. (классический метод).
Я использую системный подход (холистический метод).
Оба метода дают описание модели.
Оба метода применимы на практике.
Но системный подход сейчас сильнее продвигается, все стандарты переделаны под него, так что реально — выбора ни у Вас ни у меня нет. Только его применять.
Цель — существительное (продукт).
«Ресурс заменяем на сырье». То, что на входе предприятия. Причина: слово «ресурс» обозначает что-то иное, особенно в Управлении проектами. Может быть путаница. Используем стандартное определение (словарь) для производства на основе периодических процессов (IEC 61512)
Более корректно:
1. Оптимальное количество сырья. Значение: на 7 дней работы для каждого вида.
2. Оптимальное количество продукта. Значение: на 7 дней продаж для каждого вида.
Цель — глагол (процесс)
3. Сокращение (при цели 1). За 1 месяц на 50%.
Тогда можно проконтролировать и измерить. Если соединено все вместе — то невозможно. Попробуйте параметризировать цель «Оптимизация управление ресурсами предприятия (повышение рентабельности)». Хотя бы один параметр, не разделяя семантически само предложение. Я не умею.
То же самое про рентабельность. «Оптимизация управление ресурсами предприятия (повышение рентабельности)» Тут сразу три аспекта: функции, продукт, финансовый. Причем цель сразу связан с методами. Оптимизация — ресурсы. Повышение — рентабельность. Корректно стоит разделить на три части.
Рентабельность — неприменимый показатель в этом контексте. Не указано рентабельность чего именно: продукта, деятельности за квартал, всего предприятия.
Корректно наверное так:
Цель:
Рентабельность ROE Значение:+20% от ROE.2017
Рентабельность ROS Значение:+10% от ROS.2017
Рентабельность ROA Значение:+15% от ROA.2017
Цель:
Повышение для ROE До целевого значения. март 2018
Повышение для ROS До целевого значения. март 2018
Повышение для ROA До целевого значения. март 2018
Вот тогда можно измерить и проконтролировать.
И еще для каждого нужно указать метод измерения. Например СТО…
Благо дарю за ответ!
Тут вопрос именно методологии. Прежде всего, насчет документов. По системному подходу документы должны быть «атомизированы». То есть краткие и ограниченные. По моему опыту — не более 3-5 страниц (в эквиваленте А4). Принцип «гипертекстового знания». Пример про цели. Описание целей внедрения в Карте проекта — 2-3 предложения максимум.
Нюанс системного подхода: цель всегда указана для конкретного пользователя, только с его точки зрения, только в одном аспекте. Целей может быть 5-9. С разных точек зрения (аспект по ISO 81346).
А теперь самое сложное, потому, что совсем иная логика в системном (холистическом) подходе:
1. Одно описание цели всегда неполное, неточное, противоречивое иным целям. Даже не стремимся к уточнению!
2. Только все вместе цели дают приемлемое описание цели создания системы. Принцип аддитивной логики. Аналогия: 10 мудрецов описывают слона на ощупь в темной комнате.
3. Иерархия целей всегда многомерная. В разных аспектах — своя иерархия. Аналогия: обычно, иерархия целей строится в плоскости. А тут — многомерная структура, в объеме. Поэтому в одной системе координат одна цель — часть другой. А в иной системе координат — одна из целей вообще не существует. Целостное представление дает только суммарная, многомерная картинка.
4. Цели сформулируйте в виде существительных. Отдельно — в виде глаголов. Существительное — объект. Глагол — процесс. Никогда не совмещайте оба варианта.
5. Формулировка изначально не для понимания человеком. Изначально и всегда ориентируемся на информационную систему.
6. Более корректно принципы формулировки целей описаны в методологии LFA (Логико-структурный подход). И еще в НЛП, ищите «правила хорошо сформулированной цели».
Как бы Вы не сформулировали цели — всегда описание целей будет неполным, противоречивым и неточным! Но это не мешает работать и делать проект.
Принцип методологии реального проекта — как использовать постоянные изменения для работы проекта. Поэтому все документы проекта всегда меняются.
Кстати именно поэтому они и делаются короткими и всегда есть main document по ISO 11005 для определенной части проекта. Обычно — для каждого объекта есть такой документ. Обычно в виде списка документов, которые связаны с этим объектом.
Получаем для каждого элемента проекта есть только один документ. А в нем — список связанных документов. Не приложения к документу! А именно все отдельно.
Пример.
Классический подход: документ требования к системе (Д1). Один документ, в начале — оглавление. К нему 10 приложений со схемами или таблицами. 30-50 страниц
Системный подход: требования к системе — главный документ. В нем только типа «оглавление» из Д1 со ссылками на остальные документы. Отдельно — функциональные требования. Это документ Д2. На него есть ссылка в Д1. Но он СОВЕРШЕННО отдельный и независимый документ. Нефункциональные требования — документ Д3. Все то же самое. И так для КАЖДОГО документа, включая все бывшие приложения. Все эти документы связаны по метаинформации в репозитории документов проекта. Для чего так: Заказчику надо показать требования для экономистов. Это отдельный документ. Бери и работай. На остальные требования — не влияет. Для технологов — свой документ. И так для каждого заинтересованного лица. Свой взгляд, своя точка зрения. Свой аспект. И только все вместе — дают полный комплект требований к системе.А насколько проще все согласовать… Не надо переделывать все ТЗ. Очень просто разграничить доступ. Ну и так далее. Это не я все придумал! Я только вольно, криво и косо пересказал одну часть стандарта ISO по технической документации.
Могу дать доступ до своей электронной библиотеки, там все это есть более подробно и со стандартами. Библиотека на G suite организована, поэтому пришлите свой адрес на Гугл аккаунте gmail, и я тогда дам доступ к сайту. Доступ всегда бесплатный, но ограничен, потому, что там куча стандартов. А они типа не open source… Опаньки… Мой адрес vb@in-genium.in.
В заключение, немного целей системы ERP. Аспекты по ISO 81346, основные (= и -), дополнительные (финансовый #F и номер проекта #P для нумерации ).
Аспект функции (=):
Цели:
=F.001 Долгосрочный план. Показатель достижения цели (параметр): логический (да/нет)
=F.002 Краткосрочный план.Показатель достижения цели: логический (да/нет)
=F.003 План продукции. Показатель достижения цели: логический (да/нет)
Аспект финансовый (#F).
Цели:
#F.001 Транзакция продажи. Параметр: продолжительность. Значение: 0,1 нормочаса.
#F.002 Транзакция продажи. Параметр: затраты на осуществление. Значение: 100 рублей.
#F.003 Транзакция продажи. Параметр: количество за 1 месяц. Значение: 20 000
#F.004 Транзакция продажи. Сложность. Значение: низкая. Тип: выбор из списка «низкая» «средняя» " высокая". Метод оценки: СТО #P396=AF&BPQ001. Код документа я использовал реальный, на основе ISO 61355.
#F.005 Административные затраты. Параметр: сумма за 1 месяц. Значение: -20% Метод оценки: СТО #P396=AF&BPQ002.
Аспект продуктовый (продукт — сама система ERP).(-)
-P.001 Количество лицензий. Параметр: количество. Значение: 10
Все, надоело писать цели. Реально интеграция системы ERP по стандарту IEC 62264 может быть на 7 уровнях. Что-то типа как в модели OSI для инета. Все уровни прописаны, что где, как и когда происходит. Например,
Level 4 defines the business-related activities needed to manage a manufacturing organization.
Manufacturing-related activities include establishing the basic plant schedule (such as material use, delivery and shipping), determining inventory levels and making sure that materials are delivered on time to the right place for production.
То есть документ: #P396=AF.004&BEC001 Цели внедрения ERP будет содержать цели только для шефов отделов. И там не будет целей для уровня 5.
А для владельцев фирмы будут цели, структурированные и описанные для уровня 5. Что на этом уровне — тоже все прописано в стандарте. Получается, что в идеале будут 6-7 документов о целях внедрения системы ERP. Каждый получит только специалист с определенного уровня. И каждый документ описывает ВСЕ цели внедрения системы. Но только с точки зрения того, кому он адресован (соответствует номеру уровня) и не содержит ненужных деталей. ЦЕЛОСТЬ системы целей увидеть невозможно, и такая задача даже не ставится. То есть никакой «декомпозиции» целей, никакой «полноты, непротиворечивости» и т. п. нет и даже такая задача для ПРОЕКТА В ЦЕЛОСТИ не ставится.
Да, есть иерархия целей, да, может быть их «декомпозиция» — но только в каком-то одном аспекте. Один аспект — один документ.
Ага, и документ — это не «бумажка». А просто «обособленная часть информации». Документы для 5-6 уровня будут очень короткими. В идеале — 5-6 уровень это один абзац. Шефы это любят. А на уровне 1 — сотни, если не тысячи документов, по одному на каждый процесс.
Как все это организовать, соединять, следить? Несложно, это все тоже описано в тех же стандартах ISO IEC. По промышленным проектам — все реализовано в ePlan.
Для всего остального хватает G Suite. С технической точки зрения, для составления полной технической документации для строительства небольшого завода нужно немного времени, если применять новые методы системного подхода. Вся документация для такого проекта, вплоть до детальных списков с ценами всех элементов (до шурупа…), со всеми схемами для исполнителей, на 3 языках, делается за 1-2 дня. Если уже есть готовая библиотека типовых элементов!
Что касается проектов ИТ, или научных проектов, то все проще.
Например, мы вдвоем ведем одновременно сейчас 6 проектов:
Производство чистящих средств.
Производство краски.
Переработка промышленных отходов.
Функциональные продукты из пророщенного зерна.
Моделирование жилищного кооператива (фонда?)
Развитие сети MLM
Ну и успеваем делать методологию для ведения таких проектов. Это типа еще целый проект.
Это не потому, что мы типа крутые… Это просто такая методология, такой инструмент. Мы пока владеем им довольно посредственно. Да, с 2008 года мир сильно изменился. И да, я сам офигевал, когда читал книги по UML RUP PM и совершенно ничего не мог понять. Полная ахинея и заумь. А реально — совсем иной подход, холистический, целостный. И очень простой. Расширение классического подхода на иной логике и иной методологии.
И, кстати, про институты и про обучения. Когда я понял, что половину жизни потратил на изучение старых, кривых и косых методов — то немного разозлился на себя и на учителей. А теперь, вижу, что ни в России, ни тут в Польше ничего в обучении не поменялось. И учат точно такому же отстою. Все те же методы на основе редукционизма, нет обучения на основе системного (холистического) подхода. И тогда мне стало совсем фигово: вся эта кодла инженеров, ученых, манагаров, программастов после институтов годны только как кассиры в магазин. Приходится ПОЛНОСТЬЮ переучивать. И 50% времени — это выбивание их головы того мусора, что туда заложили в институтах. Реально — специалисты очень востребованы. Бабла платят кучу, работа — интересная. Но просто люди не понимают друг друга. Разная логика на уровне архетипов и самих основ сознания! Прикол: у некоторых людей перестройка логики при смене подходов на холистический приводит иногда просто к потере сознания. Отключка на 2-3 минуты и полная амнезия ближайших 5-10 минут разговора.
Так что все совсем не так, как мы думали… Все гораздо ЛУЧШЕ!
Прекрасно! Благодарю за информацию!
Мне довелось быть с обеих сторон разных проектов. В том числе нескольких внедрений информационных систем.
Не пишу ERP, потому что это не важно, как назвать информационную систему. Можно MRP ERP CRM 1C SAP G Suite… И да, это все совсем разные системы. Но есть у них много общего.
Прежде всего, взгляд с другой точки зрения на одну фразу из Вашего поста:
«Так вот, цель проекта – внедрение ERP-системы. „
Нюанс именно в формулировке цели. Из 27 опрошенных мною лично людей, 26 формулируют цель так: “глагол + существительное.» Например, цель школы: «получение знаний». В Вашем варианте: «внедрение системы».
Почему это ОЧЕНЬ важно: так запрограммирована голова у 99% людей. И именно поэтому очень часто возникают проблемы при реализации любого проекта. В том числе проекта ИТ. И это свойство разума есть не только в России, но и в Польше, например. Откуда это — особая тема, скажу только, что корни в редукционистском подходе в мышлении, в противовес холистического (целостного) подхода.
Чего НЕ дает такая формулировка: очень сложная параметризация цели. Например, на сколько процентов цель достигнута? Или любой иной параметр цели. Приходится скакать от параметров действия (процесса) к параметрам объекта.
Корректнее цель формулируется только существительным (можно с прилагательным, указателем свойства). И тут самый прикол: «система ERP» — вовсе не цель проекта. «Время одной продажи» — цель проекта. «Время составления заявки» — цель проекта. Значение целевого параметра «Время одной продажи» = 30 минут. Так проще и легче. Целей может быть много, но если все они выражены через существительные, то начать и ЗАКОНЧИТЬ проект внедрения с успехом — очень просто.
Оценка вариантов, консалтинг, и самое страшное — ТЗ. Можно все придумывать и набивать самому шишки.
Так БЫЛО когда-то, лет так 10 назад. Если же сейчас кто-то заикается о «Разработка технического задания» — то лучше сразу бежать как можно дальше. Причина: давно уже стандартизирован системный подход (в отличие от классического). IEEE software life cycle, там все описано. Логика совсем иная, подход холистический, одновременно в разных аспектах (аспекты по ISO 81346). И там нет ТЗ. От слова «совсем».
Насчет документов проекта: если Исполнитель прислал Заказчику SRS в виде ссылки на документ Гугла, причем на 70% SRS уже заполнен — то это профессионалы. Если сразу создали Карту проекта, План работ, Список документов проекта (main document по ISO 11005), дали доступ к стандартам Исполнителя, в которых написано, как все это заполнять — то можно начинать внедрение с таким Исполнителем. Если приходят, звонят, присылают документы по электронной почте, назначают встречи — то проект скорее всего будет провален или затянут от плана в 10 раз.
Далее, а что там у Заказчика? У Заказчика баланс на каждый день. Есть СТО (причем Стандарты процессов, а не только продуктов!), шеф Заказчика умеет пользоваться облачными сервисами, не печатает документы, в фирме пересылают документацию в налоговую с использованием ЭЦП. И самое главное: у шефа фирмы только один сотовый телефон, причем не iPhone. Тогда есть шанс, что можно внедрить у них информационную систему. Если хотя бы один пункт не выполнен — то будут проблемы и проект не закончим.
Почему так? Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.
От типовой модели организации (из тех же стандартов ISO, модель событийная, потоковая). То есть как именно должны быть построены все бизнес-процессы в фирме из определенной отрасли. Ничего не надо придумывать и даже пытаться понять, как сделано сейчас у Заказчика. Все равно, что бы не придумал Заказчик в своей фирме, все, что придумают 100500 консультантов вместе с Заказчиком, все знакомые этих консультантов, знакомые их знакомых — все это УЖЕ есть, описано, оптимизировано, в виде моделей до уровня «поле такое-то, тип текстовый, 256 символов» в соответствующем стандарте. То есть совершенно до таких деталей, что аж офигеваешь…
Например, периодические процессы производства описаны в стандарте IEC 61512 с деталями организации как технологии, так и архитектуры системы. Например, для проекта по краске мы использовали около 15% возможностей, там описанных. И этого хватило для всех технологов и «манагаров» и экономистов, и бухгалтеров, и директоров всех уровней. Были ОЧЕНЬ рады, что рецептуры теперь совсем иначе делаются, намного проще, удобнее, и быстрее. Время создания комплекта документов сократилось с 240 до 40 (!!) нормочасов. И это только применение стандартных ПРОЦЕССОВ! Как эти процессы соединить между собой — тоже все уже описано и стандартизировано в виде best practice. И на основании типовых схем собираем цепочку для получения нужного продукта. Какого? А тут полная воля для Заказчика и для всех его “манагаров”. Любого продукта. Но по стандартным процессам!
Нужно ERP подключить? Очень просто! Стандартная структура фирмы по определенному ISO для конкретной отрасли. Плюс стандартные процессы по тем же стандартам ISO, плюс стандартные желания и требования Заказчика (которые всегда будут не более, чем 15% от тех же стандартов ISO). И стыкуем по стандартной модели из стандарта IEC 62264. И такт стандарты и готовые модели и рекомендации есть по КАЖДОМУ процессу по каждому элементу бизнес-системы у Заказчика.
Никогда еще мне не пришлось столкнуться, чтобы Заказчик чего-то придумал такого, чего УЖЕ нет в стандарте на какой-то процесс. Поэтому внедрение ERP MRP и подобных систем — тупая рутина, типа как внедрение «текстового редактора» у себя дома.
Не парьтесь! Изучайте системный подход, стандарты типовых ПРОЦЕССОВ из ISO IEC IEEE ANSI EN BS, выкиньте кривые ГОСТы (они устарели лет на 15 минимум), а всех, кто говорит про ТЗ — отправляйте в пешее эротическое путешествие.
Прелестно!
Управление безопасностью ISO 27k (27001-27010, и иные),
Это основа для достижения цели.
Правовое регулирование там это примерно 10% успеха.
Техническое регулирование (как часть правового регулирования) — 5%.
Регулирование как форма целенаправленного управляющего воздействия, ориентированного на поддержание равновесия в управляемом объекте и на его развитие посредством введения в него регуляторов (норм, правил, целей, связей) — уже лучше.
Остальные элементы управления безопасностью из упомянутого стандарта не менее важны.
Опять же безопасность ЧЕГО? Процесс, продукт, место расположения (три базовых аспекта).
IOT только лишь интерфейс, соединяющий чего-то с чем-то. Быстро, просто дешево — но в реальном мире это только метод связи. Ничего более.
По-хорошему нужен анализ рисков всей системы, которая нас интересует, как «регуляторов».
Например, можно заморочиться и подключить все устройства через хаб. Или по промышленному стандарту типа CAN. Снаружи не влезть. Изнутри можно скомпрометировать.
Все это простейшие примеры, спецы все знают лучше меня.
Анализировать придется с точки зрения надежности систем, с точки зрения безопасности системы, с точки зрения права, и т. д
Хотя результат предсказуемый: все упрется в человека. Оператора, админа, менеджера и т. п.
Поэтому стоит слабое звено вообще удалить. А технически построить систему на принципах непрерывной логики. Суть: каждый элемент системы работает нестабильно, связь элементов системы также нестабильна. А целевой результат работы системы в целом находится в заданных рамках (более-менее стабилен).
Как-то так.
Ну и про IOT и его регулирование.
Подход при регулировании — не системный. А «классический». Поэтому ничего не получится «регулировать». Почему?
А очень просто: ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011
«Сложность искусственных систем достигла беспрецедентного уровня. Это открыло новые возможности и вместе с тем привело к усложнению проблем для организаций, которые создают и используют такие системы. „
Проще говоря: системы стали настолько сложными, что понять их стало невозможно. Даже частично, даже “в общем». От слова «совсем никак». Но есть методы как проектировать или анализировать такие системы. И да, так и пришли к «системному подходу».
Перестроить мозги на системный подход — сложно, а иногда и невозможно. Прикол: у некоторых людей изменение архетипов при таком процессе приводят просто к потере сознания и амнезии последних 5-10 минут общения. И это не один случай, а уже много (в моем личном опыте).
Поэтому не парьтесь! Юристы и законодатели все равно ничего сделать не смогут. Все упрется снова в программистов. Что, собственно, и происходит уже не один год.
Ну вводят какие-то методы регуляции чего-то там в Инете. Ну влияют они на 100500 человек. Все в пределах погрешности работы сложной системы.
Ну и прикол напоследок: спросите у знакомых, какова цель школы или института? Все ответят в одном стиле: сказуемое + подлежащее. «Получение знаний», например. Цель бизнеса? «Получение прибыли». Цель регулирования? «Борьба с экстремизмом».
Тут и самое страшное: цель соединена с действием. Цель школы — «знания». Цель бизнеса — «прибыль» или «стоимость компании». Только тогда можно что-то померять (значение параметра). Параметр — только существительное!!!
Цель регулирования?… Вот-вот, фиг сформулируете…
Учим матчасть!
«холистический подход» и «системный подход» не синонимы.
Системный подход — построен, связан с холистическим подходом. Один из вариантов реализации холистического подхода. Примерно так.
В том и фишка, что в разных аспектах всегда будет разное понимание.
И все они правильные. Разные понимания дополняют друг друга, хотя могут частично противоречить. И да, конечно же разные люди иначе понимают и подразумевают значения этих слов. Есть что-то общее — его и ищем и применяем. А разное — игнорируем или просто перекладываем на приоритет ниже. Потом типа согласуем.
«словосочетания «классический подход»»
Я использовал их, потому, что более-менее так они обозначены, например, в книге Wasim — Standards for engineering design and manufacturing. 2006.
Резюме по этой книге тут https://drive.google.com/open?id=1qYp257bZadYd_2sN3hHwWNSF7l0u8PmsTVHXKQxdHw8
Термины за 10 лет устоялись, но в разной среде — по разному.
Для ученых — это нечто странное.
Для инженеров — рутина, «а как же может быть иначе?», особенно в электротехнике. Пример: ePlan.
Для программистов — на уровне архитектуры программ, принципов программирования — тоже само собой разумеется.
Для программистов на уровне управления проектом — уже не так очевидно и понятно.
Для менеджеров проектов — ежедневная рутина, но часто без понимания принципов. Типа «так шеф
сказал делать.»
Для финансистов при до-финансировании проектов в Европе — это бардак из набора стандартных документов, криво и косо составленных. Потому, что в голове каша из двух подходов.
Для производителей еды — это просто требования HACCP, в 90% случаев — отношение «какие-то бумажки снова делать...»
Для иного производства — это система ISO 9000. Опять же, «непонятная фигня, но делать бумажки приходится...»
Так что в разных группах — очень по-разному отношение и понимание.
Хотя, с другой стороны, мнение ВСЕХ, кто «не понимает» или кому лень разбираться — не играет никакого значения. Согласен или не согласен, понял или не понял — все равно будешь применять именно системный подход. Вопрос только времени и положения.
Понял — делаешь быстро и работаешь шефом. Не понял — делаешь медленно и работаешь исполнителем.
Кстати, разница в производительности катастрофическая: один и тот же документ для финансирования проекта делается за 40 нормочасов или за 270 нормочасов.
40 — если понимаешь системный подход. 270 — если нет. Отсюда и уровень оплаты, ведь платят за результат, и сумма — одинаковая в обеих случаях. Поэтому приходится учить матчасть.
Как-то так.
Редукционизм и холизм — основы методов познания. На них все построено.
Метафора из геометрии: есть в трехмерке цилиндр. Правый вид (проекция) на плоскость — это прямоугольник. Вид сверху (тоже проекция) — окружность. Это «аспекты» из ISO 81346. То, что видим с определенной точки зрения. Методы редукционизма (классические): видим одну проекцию.
Говорим только о ней. Модель одна, стремимся к точности, полноте, непротиворечивости. Классификация — линейная, двумерная, иерархическая. Объект «состоит из» частей. Есть конкурирующие точки зрения, один говорит «прямоугольник», другой — «нет, круг». Методы — дискуссия, «в споре рождается истина» и т. п.
Холистический подход: (системный). Видим одну проекцию, но всегда учитываем, что есть еще иные проекции. Говорим об одной проекции, потом о другой, потом от третьей. Только все проекции (модели) вместе и одновременно дают представление об цилиндре. Моделей множество, нет целей получить точные, непротиворечивые и своевременные модели. Классификация параллельно в нескольких аспектах (трехмерная), не иерархическая, аддитивная. В объекте можно выделить части в определенном аспекте. Но это не значит, что есть только эти части! Всегда есть целость, всегда выделение частей неточное, неполное. И поведение частей это одно. А поведение целости — это нечто иное. Точки зрения (модели) дополняют друг друга, хотя могут быть противоположными по смыслу, могут частично совпадать, могут противоречить одна другой. Методы: обсуждение только общих частей моделей, поиск совместного видения целого, дискуссии запрещены принципиально. Пример: если в документе что-то сильно не так, с точки зрения редактора, то делается форк документа (новая версия), а не ищется консенсус.
Это коротко про подходы. Системный подход — часть холистического мировоззрения.
Материалы у меня есть, если интересно — пишите на майл vb@in-genium.in, включу доступ (всегда бесплатно, то есть даром). Это моя библиотека (сайт на G Suite), там куча стандартов ИСО, поэтому доступ не открытый :-)
Ну и напоследок: с 2008 года системный подход внедрен ВЕЗДЕ на уровне стандартов деятельности (процессов, а не только продуктов). Поэтому применять придется, хотим того или нет. Ни вашего, ни моего желания никто не спрашивает. И да, все именно так. Если нужны примеры — то все покажу и обосную. Для каждой отрасли, для каждого вида деятельности.
Вы правы. Все уже есть. Целое семейство стандартов ISO EN по безопасности для разных систем.
ВСЕ такие стандарты построены по одному принципу (Цикл Деминга, PDCA).
цикл «планирование-действие-проверка-корректировка» Обратите внимание: ключевое слово — цикл!
Главная проблема внедрения этих стандартов (по моему личному опыту в России и Польше) четко сформулирована много лет назад Чеховым: «Дело не в пессимизме и не в оптимизме, а в том, что у девяноста девяти из ста нет ума. „
Для начала: на концептуальному уровне, на уровне архитектуры системы и и даже на уровне “use-case» ничего придумывать и разрабатывать не надо. Все уже есть. на 90% все уже есть в виде типовых решений на уровне приложений и протоколов. И даже на уровне кода и программ есть все нужное на 60-70% для всех видов элементов системы.
Проблема острейшая на уровне управления проектами по конкретному изделию.
Не читают стандартов. Не планируют. Пытаются что-то делать, тратят 90% времени. На проверку и корректировку уже нет ни сил ни времени. Очень коротко так выглядит этот балаган.
Основная причина нетривиальная: многие люди применяют «классический» подход к деятельности. Также известный, как «редукционизм».
А большинство стандартов, готовых продуктов, протоколов, программ, документов, принципов работы, методов сертификации — построены на системном подходе. Также известен, как «холистический подход».
Вроде бы некая сугубо научная ботва, ну что такого? А результат страшный: базовая логика в этих подходах разная. Что приводит к тому, что инженер тупо не понимает, о чем вообще речь? Типовая реакция: «Че за фигня, зачем писать кучу бумажек?? Когда работать-то будем??»
А на уровне законодателей вообще полный привет. Они обычно даже на банкетах умом не блещут, а уж в общей теории систем там вообще конь не валялся…
Возможное направление развития только на уровне техники и технологии (код, протоколы, железо). А людишки подтянутся… То есть все законодательные инициативы — малоэффективны в сравнении с усовершенствованием Управления Проектами в конкретной фирме.
О! Огромное спасибо! Иная точка зрения на правовые вопросы.
Предлагаю еще сильнее обострить в этом направлении.
Очень важным, мне кажется, будет ответ на вопрос: может ли существовать и применяться криптовалюта вообще без легитимизации в юридическом аспекте? Нужен ли вообще юридический аспект при построении моделей отношений с использованием крипто-технологий?
Из всего, что пока я понимаю — ответ отрицательный. Крипто системам не нужна легитимизация в традиционном праве. Совсем не нужна. А все потенциальные и реальные проблемы при транзакциях можно решить ТЕХНИЧЕСКИМИ методами. Более обидно: крипто-системе глубоко по-фигу на мнения или чаяния юридической системы.
Можно посмотреть с такой точки зрения:
Крипто-технологии, крипто-валюты — это отдельный слой реализации протокола взаимодействия между субъектами. По аналогии со слоями (и принципами) OSI, на которых построена коммуникация Инета.
С этой точки зрения, традиционное право — только один из слоев такого взаимодействия.
Крипто-слой в этой модели — параллельный слой для слоя традиционного права.
В крипто-слое реализованы ВСЕ функции, протоколы слоя традиционного права.
Основа использования традиционного права, как защитного механизма, построена на нескольких допущениях:
1. При отношениях (транзакции) может возникнуть конфликт.
2. Множество слабых людей могут победить одного очень сильного. Можно иначе: большая и сильнейшая система побеждает меньшую и слабейшую. Система, у которой больше элементов и более совершенные связи считается более сильной. Это если рассматривать право с точки зрения теории систем (упрощенно).
3. Элементы системы (субъекты) в системе права соединяются едиными законами.
Есть и иные допущения, но пока они не рассматриваются. Все эти функции реализованы так или иначе, криво или не очень в имеющихся крипто-протоколах, крипто-валютах.
Может ли быть интерфейс между слоями крипто и традиционного права? Может быть. А может и не быть. Это как будут себя вести юристы. Вопрос за 2 года встал по иному: если юристы почешутся, то крипто-технологии обратят на них внимание и будут сотрудничать. Если нет — идите лесом… Да, именно так остро. Все просто: смотрите на инвестиции в эту область: финтех — 5 — 15 — 75 млрд баксов. Динамика за 3 последних года. И это только часть крипто-технологий.
И что самое веселое: если технологии финтех первыми внедрят банки — то государство лишится функции на эмиссию денег. Совсем лишится. Будет только сторожевым псом определенной территории. А это — на 90% трандец амбициям всех «групп интересов».
Если же технологии финтех первым внедрит государство — то банки лишаться функции клиринга и платежей. То же на 90% трандец амбициям шефов банков.
Так что веселье только начинается. Устраиваемся поудобнее и радуемся!
PS
Насчет интерпретации криптовалюты в рамках юридической системы. Криптовалюта — нематериальный актив. Набор ОТКРЫТОЙ информации, которая имеет ценность для владельца. https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BC%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D1%8B
«использование в течение длительного времени» и «компания не предполагает последующую перепродажу данного имущества в течение 12 месяцев» обходятся очень просто, а все остальное — подходит.
Тогда все операции — договор мены. И тут начинается супер-веселье…
Пишем код, а не кодексы… А юристы — потом подтянутся…
А еще террористы пользуются оружием. Может быть в эту сторону больше усилий сосредоточить?
А еще — взрывчатыми веществами. Может быть контроль ВВ сделать на основе специальных датчиков? Они есть.
А еще — пользуются глупостью людей. Может быть повысить уровень образования? Пропаганды?
А еще — они едят еду. Может быть отравить всю еду, чтобы они просрались? :-)
Стойкое шифрование известно уж много лет. Технически его применение никак не ограничить.
Поздновато пить боржоми, почки уже отвалились.
Да, можно запретить дуть ветру. И что? Выполнить такой запрет можно только технически, не административно.
Ну и насчет агитации, вербовки и т. п… Специалисты знают как с этим бороться, и каналы вербовки не очень важны. Если кто-то где-то что-то заявляет о важности отключения шифрования — то это плохие специалисты. Оценивайте именно так.
iCpu
Все верно. Вы правы. Кто-то кого-то должен защищать. В фантазиях — это так. В реальной жизни — нет.
Никто не защитит Вас от самого себя. А прежде всего, 90% всех проблем в онлайне — от личной глупости. Или от чувства собственной значимости.
Например, клевета. Если меня не интересует мнение других людей — то клевета на меня невозможна. То есть это по сути мое отношение к реальности, причем тут государство?
То же самое про право на забвения в Инете. Оно не нужно, если меня лично устраивает полная открытость и полная информация обо мне. Если Вам такая открытость неприятна, то решения два: сменить свою оценку события. Или найти техническое решение, чтобы на Вас открытость не влияла. Опять же, это только Ваша квалификация и знания. Не знаете как сделать? Учите матчасть. Зачем снова надеяться на кого-то? На государство, на админов и т. п. Да, раньше так было сделать проще.
Типа поручить профессионалу заботу о себе любимом. Но за 200 лет кое-что изменилось, если Вы заметили. Государство теперь, это просто большая корпорация с несколькими группами интересов. И ни Вы, ни я, ни еще 100500 обычных людей не входят в эти группы интереса. Так что зачем пытаться использовать старые методы? Они перестали быть эффективными. Есть иные методы. Да, они сложнее. И что? Компьютер тоже стал сложнее за последние 20 лет. Это же никого не беспокоит.
Мне кажется, что путь совсем иной: не пытаться использовать старые социальные методы, типа государства. А использовать новые методы, например на основе блокчейн. Много идей есть у Джима Белла. Много есть в системах на основе smart contract. Много можно использовать методов из социальной психологии в связке с ФБ и социальными сетями. Так что государство (или подобные структуры) тут не причем.
>Например, сегодня мы (я и команда) получили рекомендацию написать открытое письмо по криптовалютам, >обращённое к тем, кто разрабатывает под них закон.
Идея прелестная! Хотя есть одна трудность: ни читают. Написать-то можно. Точнее, может кто-то и прочитает. Но мало кто поймет хоть что-то. Поэтому не будет никакой реакции.
Причина простая: низкая квалификация.
Хотя, по сути, проблема «электронных денег», «криптовалюты» в рамках права представляет небольшой интерес. С одной стороны: среда обращения — иная реальность, параллельное правовое поле. Так что просто по-фигу, лично мне. Все потуги что-то регулировать упрутся в техническую сторону. А ее не решат, потому, что — низкая квалификация (см. выше).
С другой стороны, сам объект не существует. От слова совсем. В материальном виде «цифровых денег» нет. Отсюда интересный вывод: в МОДЕЛИ реальности (интерпретация цифровых денег, как информационного объекта) можно придать ОБРАЗУ любое значение. В том числе, и переменное значение. Разные аспекты объекта могут существовать одновременно. По простому — как хочу, так и кручу. Например, «цифровые деньги» просто текст. Мне нравится читать на этом языке, и ничего иного он не значит. Или «цифровые деньги» — это нематериальный актив. Типа программы. Тогда меняем один актив на другой. Причем тут оценка? Договор мены — непростая позиция. Особенно, если привязать фактор времени. Сколько стоил биткойн? А сколько сейчас? А как измерять ценность кода? А если кодом одного биткойна зашифровали мое любимое фото, и я готов отдать за этот КЛЮЧ к расшифровке 100500 баксов? Я ведь нарисую тогда любую справку, проведу 1500 экспертиз государственных, и все они подтвердят ЦЕННОСТЬ, важность, значимость именно этого кода для меня. Так что чудить можно по-тяжелому.
Мы когда-то так чудили с «мусорными» векселями. Они стоили 5% от номинала. А списать можно было полный номинал в затраты. Почему? Потому, что так на нем написано. И ничего не смогли сделать налоговики. Тут же вариантов еще больше.
Но зачем все это? Проще вообще уйти полностью в параллельное правовое поле. Тем более, что Джим Белл еще в 1990 году придумал, как исчезнут все политики, правители и законодатели. Тогда это было ТЕХНИЧЕСКИ невозможно реализовать, хотя ЭКОНОМИЧЕСКИ — все было супер! А теперь есть возможность технической реализации его идей Assasins Politics. Так что правители вваливают кучу бабла в финтех — будет кирдык банкам. А когда финтех мощно заработает (на уровне бытовухи) — то кирдык правителям. Идеи Джима Белла никуда не делись, все известно и доступно. И да, там много тонкостей, много вопросов. Ну и что? Все решаемо…
Огромное спасибо! Я сам перепробовал множество разного софта в своей работе.
И сейчас перебираюсь полностью на инструменты гугла. ОТ использования продуктов микрософт отказался почти полностью.
С точки зрения системологии и инженерии продукты (сервисы) гугла построены оптимально.
Мне нужна система для лабораторного журнала при разработке сложной химической продукции — за 2-3 часа я сделал такую систему и тоже на таблицах Гугла. Специализированные решения от Agilent и иных *удаков имеют меньший функционал и крайне неудобны в работе.
Управление проектами уровня 2-3 млн рублей, государственное дофинансирование R&D работ 5-10 млн рублей, технические проекты уровня предприятия (5-10 млн рублей) — все прекрасно реализуется на GSuite.
Это с точки зрения бизнес-процессов. Инструмент модульный, простой, оптимальный.
В Аспекте работы командой или одиночкой: сначала есть таблицы и документы, делай сам. Потом я перешел на корпоративный вариант (платный, по 4 евро на рыло) — инструменты остались те же самые, просто возрос функционал. Читал недавно про более продвинутые планы — тот же подход. Все просто, ясно и шаг за шагом.
Главное — можно работать командой, дистанционно, одновременно. и НЕ НАДО «пердолить осла» с информатиками, чтобы получить такую возможность. Все работает БЕЗ приглашения каких то специалистов и танцов с софтом и железом.
в Аспекте функционала: есть все, что НЕОБХОДИМО. Рюшечки — можно допилить. Кстати, я вчера задумался (пока этап анализ идеи) над программой, которая бы реализовала систему MRP и остальной учетный функционал типа 1С, только на инструментах гугла. Не бух учет! А именно контролинг! В виде открытой платформы, модульной, причем со встроенными системами работы с технологиями финтех (блокчейн, DAO). Было бы очень прикольно нужно.
в Аспекте программирования:
основа — nonSQL базы данных. Что еще нужно лучше? А что ЕСТЬ реально лучше?
проблемы масштабирования решаются модернизацией инструмента до более высокой версии. Гугл, если что, вроде работает, как система, с немаленькой нагрузкой…
фреймворки для архитектуры — все есть
языки — какие не лень, те и применяй
работа на таблетах и телефонах — вроде как реализовано.
более-менее все стандартизировано — да.
система безопасности — тоже есть. Вопрос тут спорный, но есть простой критерий: проведите аудит своей локальной системы на том же уровне, что гугл — тогда можно сравнивать, кто лучше.
Как-то так…
Еще раз, огромное спасибо!
Очень интересная интерпретация. Благо дарю!
Хотел бы немного с иной точки зрения посмотреть на биткойн.
Есть «слой» реальности, где действует право. Например, те или иные законы в России.
Есть «слой» в котором работают биткойны.
Предлагаю не смешивать эти «слои» и не пытаться применять к биткойнам правила права.
Да, могут быть интерфейсы между «слоями». Но пытаться притянуть правила одного мира в другой мир?
Да и не зачем этого делать. Может быть иная позиция: мне, как пользователю биткойна и технологий блокчейн нет никакого дела до государства и до права. Пусть чудят в своем слое как хотят. Просто игнор. Собака лает — ветер носит. И это реально.
А вот интерфейс между этими слоями — это иное дело. Он может быть сетевым, хаотически возникающим и пропадающим. Можно использовать дырки в законах и доводить из до абсурда, для целей работы этого интерфейса. Как такой вариант?
Все верно написано. Нет смысла повторять имеющиеся решения или пытаться разрабатывать свою собственную электронику. Однако сама логика импортзамещения в электронике корявая. Суть практически всех предложений в аспекте безопасности можно свести примерно вот к чему: сами сделаем безопасные элементы системы и тогда система в целости будет безопасная. Термин «аспект» используется из стандарта ISO 81346.
Такой подход — только один из возможных. Есть иные подходы для решения задач безопасности систем. Например, давно уже используются методы выявления и коррекции неисправностей элементов систем на основе непрерывной логики. Занимались этим В.И. Левин и компания.
Главное: можно построить надежную систему из неправильно работающих элементов. Причем ВСЕ элементы могут работать неправильно, по случайным законам («глючить»). Но система в целости будет всегда давать правильный результат. Лишь бы хоть как-то работала.
Поэтому проектирование электроники в российских реалиях может быть построено на иных принципах:
1. Покупаем самый ненадежный китайский отстой, старый хлам и вообще не морочимся ни на качестве, ни на «закладках» в элементах. Цена за процессоры и иные элементы будет по 1 баксу за ведро. Какие? А хотя бы Espressif Systems системы типа ESP8266 или AllWinner, в общем самого низкого ценового диапазона.
2. Проектируем системы на основе принципов непрерывной логики (и им подобных, сейчас много есть иных вариантов) из этого хлама. Хотя как посмотреть: ESP32 в количестве 1000 штук спокойно заменят Elbrus-4.
3. Пихаем в эти системы оригинальный софт, уже свой собственный. Но делаем его корректно, красиво, правильно!
4. Архитектура систем и софт как раз и будут направлены на то, чтобы из принципиально нестабильных элементов получить правильно и стабильно работающую систему.
5. Применяем этот же подход не только к электронике, но и к политике.
Радуемся!
Благодарю за полезную статью!
Немного выйду за пределы программирования.
При анализе в любом проекте столкнулся именно с проблемой мифологичного сознания.
Ученые, разработчики, аналитики, причем неплохого уровня уверены, что в материальном мире есть объекты, частицы, «черные дыры» и т. п. И это серьезная проблема!
Они уверены, что модели в мифологическом сознании есть в реальности!
Достучаться до них очень сложно!
Очень помогает стандарт ISO 81346, но только для технических специалистов.
У ученых, физиков, химиков такая каша в голове, что просто дым и чад.
Я сам столкнулся с проблемой вменяемой информации на темы объектно-ориентированного мышления.
Если есть какие-то ресурсы — просьба поделиться.
Уже пишу статьи. Будет не одна, а скорее всего много. Материл есть, надо причесать и некоторые части перевести с польского и английского.
Цели у Вас msin указаны и сформулированы совершенно правильно!
Просто Вы используете одну методологи. (классический метод).
Я использую системный подход (холистический метод).
Оба метода дают описание модели.
Оба метода применимы на практике.
Но системный подход сейчас сильнее продвигается, все стандарты переделаны под него, так что реально — выбора ни у Вас ни у меня нет. Только его применять.
«Ресурс заменяем на сырье». То, что на входе предприятия. Причина: слово «ресурс» обозначает что-то иное, особенно в Управлении проектами. Может быть путаница. Используем стандартное определение (словарь) для производства на основе периодических процессов (IEC 61512)
Более корректно:
1. Оптимальное количество сырья. Значение: на 7 дней работы для каждого вида.
2. Оптимальное количество продукта. Значение: на 7 дней продаж для каждого вида.
Цель — глагол (процесс)
3. Сокращение (при цели 1). За 1 месяц на 50%.
Тогда можно проконтролировать и измерить. Если соединено все вместе — то невозможно. Попробуйте параметризировать цель «Оптимизация управление ресурсами предприятия (повышение рентабельности)». Хотя бы один параметр, не разделяя семантически само предложение. Я не умею.
То же самое про рентабельность. «Оптимизация управление ресурсами предприятия (повышение рентабельности)» Тут сразу три аспекта: функции, продукт, финансовый. Причем цель сразу связан с методами. Оптимизация — ресурсы. Повышение — рентабельность. Корректно стоит разделить на три части.
Рентабельность — неприменимый показатель в этом контексте. Не указано рентабельность чего именно: продукта, деятельности за квартал, всего предприятия.
Корректно наверное так:
Цель:
Рентабельность ROE Значение:+20% от ROE.2017
Рентабельность ROS Значение:+10% от ROS.2017
Рентабельность ROA Значение:+15% от ROA.2017
Цель:
Повышение для ROE До целевого значения. март 2018
Повышение для ROS До целевого значения. март 2018
Повышение для ROA До целевого значения. март 2018
Вот тогда можно измерить и проконтролировать.
И еще для каждого нужно указать метод измерения. Например СТО…
Тут вопрос именно методологии. Прежде всего, насчет документов. По системному подходу документы должны быть «атомизированы». То есть краткие и ограниченные. По моему опыту — не более 3-5 страниц (в эквиваленте А4). Принцип «гипертекстового знания». Пример про цели. Описание целей внедрения в Карте проекта — 2-3 предложения максимум.
Нюанс системного подхода: цель всегда указана для конкретного пользователя, только с его точки зрения, только в одном аспекте. Целей может быть 5-9. С разных точек зрения (аспект по ISO 81346).
А теперь самое сложное, потому, что совсем иная логика в системном (холистическом) подходе:
1. Одно описание цели всегда неполное, неточное, противоречивое иным целям. Даже не стремимся к уточнению!
2. Только все вместе цели дают приемлемое описание цели создания системы. Принцип аддитивной логики. Аналогия: 10 мудрецов описывают слона на ощупь в темной комнате.
3. Иерархия целей всегда многомерная. В разных аспектах — своя иерархия. Аналогия: обычно, иерархия целей строится в плоскости. А тут — многомерная структура, в объеме. Поэтому в одной системе координат одна цель — часть другой. А в иной системе координат — одна из целей вообще не существует. Целостное представление дает только суммарная, многомерная картинка.
4. Цели сформулируйте в виде существительных. Отдельно — в виде глаголов. Существительное — объект. Глагол — процесс. Никогда не совмещайте оба варианта.
5. Формулировка изначально не для понимания человеком. Изначально и всегда ориентируемся на информационную систему.
6. Более корректно принципы формулировки целей описаны в методологии LFA (Логико-структурный подход). И еще в НЛП, ищите «правила хорошо сформулированной цели».
Как бы Вы не сформулировали цели — всегда описание целей будет неполным, противоречивым и неточным! Но это не мешает работать и делать проект.
Принцип методологии реального проекта — как использовать постоянные изменения для работы проекта. Поэтому все документы проекта всегда меняются.
Кстати именно поэтому они и делаются короткими и всегда есть main document по ISO 11005 для определенной части проекта. Обычно — для каждого объекта есть такой документ. Обычно в виде списка документов, которые связаны с этим объектом.
Получаем для каждого элемента проекта есть только один документ. А в нем — список связанных документов. Не приложения к документу! А именно все отдельно.
Пример.
Классический подход: документ требования к системе (Д1). Один документ, в начале — оглавление. К нему 10 приложений со схемами или таблицами. 30-50 страниц
Системный подход: требования к системе — главный документ. В нем только типа «оглавление» из Д1 со ссылками на остальные документы. Отдельно — функциональные требования. Это документ Д2. На него есть ссылка в Д1. Но он СОВЕРШЕННО отдельный и независимый документ. Нефункциональные требования — документ Д3. Все то же самое. И так для КАЖДОГО документа, включая все бывшие приложения. Все эти документы связаны по метаинформации в репозитории документов проекта. Для чего так: Заказчику надо показать требования для экономистов. Это отдельный документ. Бери и работай. На остальные требования — не влияет. Для технологов — свой документ. И так для каждого заинтересованного лица. Свой взгляд, своя точка зрения. Свой аспект. И только все вместе — дают полный комплект требований к системе.А насколько проще все согласовать… Не надо переделывать все ТЗ. Очень просто разграничить доступ. Ну и так далее. Это не я все придумал! Я только вольно, криво и косо пересказал одну часть стандарта ISO по технической документации.
Могу дать доступ до своей электронной библиотеки, там все это есть более подробно и со стандартами. Библиотека на G suite организована, поэтому пришлите свой адрес на Гугл аккаунте gmail, и я тогда дам доступ к сайту. Доступ всегда бесплатный, но ограничен, потому, что там куча стандартов. А они типа не open source… Опаньки… Мой адрес vb@in-genium.in.
В заключение, немного целей системы ERP. Аспекты по ISO 81346, основные (= и -), дополнительные (финансовый #F и номер проекта #P для нумерации ).
Аспект функции (=):
Цели:
=F.001 Долгосрочный план. Показатель достижения цели (параметр): логический (да/нет)
=F.002 Краткосрочный план.Показатель достижения цели: логический (да/нет)
=F.003 План продукции. Показатель достижения цели: логический (да/нет)
Аспект финансовый (#F).
Цели:
#F.001 Транзакция продажи. Параметр: продолжительность. Значение: 0,1 нормочаса.
#F.002 Транзакция продажи. Параметр: затраты на осуществление. Значение: 100 рублей.
#F.003 Транзакция продажи. Параметр: количество за 1 месяц. Значение: 20 000
#F.004 Транзакция продажи. Сложность. Значение: низкая. Тип: выбор из списка «низкая» «средняя» " высокая". Метод оценки: СТО #P396=AF&BPQ001. Код документа я использовал реальный, на основе ISO 61355.
#F.005 Административные затраты. Параметр: сумма за 1 месяц. Значение: -20% Метод оценки: СТО #P396=AF&BPQ002.
Аспект продуктовый (продукт — сама система ERP).(-)
-P.001 Количество лицензий. Параметр: количество. Значение: 10
Все, надоело писать цели. Реально интеграция системы ERP по стандарту IEC 62264 может быть на 7 уровнях. Что-то типа как в модели OSI для инета. Все уровни прописаны, что где, как и когда происходит. Например,
Level 4 defines the business-related activities needed to manage a manufacturing organization.
Manufacturing-related activities include establishing the basic plant schedule (such as material use, delivery and shipping), determining inventory levels and making sure that materials are delivered on time to the right place for production.
То есть документ: #P396=AF.004&BEC001 Цели внедрения ERP будет содержать цели только для шефов отделов. И там не будет целей для уровня 5.
А для владельцев фирмы будут цели, структурированные и описанные для уровня 5. Что на этом уровне — тоже все прописано в стандарте. Получается, что в идеале будут 6-7 документов о целях внедрения системы ERP. Каждый получит только специалист с определенного уровня. И каждый документ описывает ВСЕ цели внедрения системы. Но только с точки зрения того, кому он адресован (соответствует номеру уровня) и не содержит ненужных деталей. ЦЕЛОСТЬ системы целей увидеть невозможно, и такая задача даже не ставится. То есть никакой «декомпозиции» целей, никакой «полноты, непротиворечивости» и т. п. нет и даже такая задача для ПРОЕКТА В ЦЕЛОСТИ не ставится.
Да, есть иерархия целей, да, может быть их «декомпозиция» — но только в каком-то одном аспекте. Один аспект — один документ.
Ага, и документ — это не «бумажка». А просто «обособленная часть информации». Документы для 5-6 уровня будут очень короткими. В идеале — 5-6 уровень это один абзац. Шефы это любят. А на уровне 1 — сотни, если не тысячи документов, по одному на каждый процесс.
Как все это организовать, соединять, следить? Несложно, это все тоже описано в тех же стандартах ISO IEC. По промышленным проектам — все реализовано в ePlan.
Для всего остального хватает G Suite. С технической точки зрения, для составления полной технической документации для строительства небольшого завода нужно немного времени, если применять новые методы системного подхода. Вся документация для такого проекта, вплоть до детальных списков с ценами всех элементов (до шурупа…), со всеми схемами для исполнителей, на 3 языках, делается за 1-2 дня. Если уже есть готовая библиотека типовых элементов!
Что касается проектов ИТ, или научных проектов, то все проще.
Например, мы вдвоем ведем одновременно сейчас 6 проектов:
Производство чистящих средств.
Производство краски.
Переработка промышленных отходов.
Функциональные продукты из пророщенного зерна.
Моделирование жилищного кооператива (фонда?)
Развитие сети MLM
Ну и успеваем делать методологию для ведения таких проектов. Это типа еще целый проект.
Это не потому, что мы типа крутые… Это просто такая методология, такой инструмент. Мы пока владеем им довольно посредственно. Да, с 2008 года мир сильно изменился. И да, я сам офигевал, когда читал книги по UML RUP PM и совершенно ничего не мог понять. Полная ахинея и заумь. А реально — совсем иной подход, холистический, целостный. И очень простой. Расширение классического подхода на иной логике и иной методологии.
И, кстати, про институты и про обучения. Когда я понял, что половину жизни потратил на изучение старых, кривых и косых методов — то немного разозлился на себя и на учителей. А теперь, вижу, что ни в России, ни тут в Польше ничего в обучении не поменялось. И учат точно такому же отстою. Все те же методы на основе редукционизма, нет обучения на основе системного (холистического) подхода. И тогда мне стало совсем фигово: вся эта кодла инженеров, ученых, манагаров, программастов после институтов годны только как кассиры в магазин. Приходится ПОЛНОСТЬЮ переучивать. И 50% времени — это выбивание их головы того мусора, что туда заложили в институтах. Реально — специалисты очень востребованы. Бабла платят кучу, работа — интересная. Но просто люди не понимают друг друга. Разная логика на уровне архетипов и самих основ сознания! Прикол: у некоторых людей перестройка логики при смене подходов на холистический приводит иногда просто к потере сознания. Отключка на 2-3 минуты и полная амнезия ближайших 5-10 минут разговора.
Так что все совсем не так, как мы думали… Все гораздо ЛУЧШЕ!
Мне довелось быть с обеих сторон разных проектов. В том числе нескольких внедрений информационных систем.
Не пишу ERP, потому что это не важно, как назвать информационную систему. Можно MRP ERP CRM 1C SAP G Suite… И да, это все совсем разные системы. Но есть у них много общего.
Прежде всего, взгляд с другой точки зрения на одну фразу из Вашего поста:
«Так вот, цель проекта – внедрение ERP-системы. „
Нюанс именно в формулировке цели. Из 27 опрошенных мною лично людей, 26 формулируют цель так: “глагол + существительное.» Например, цель школы: «получение знаний». В Вашем варианте: «внедрение системы».
Почему это ОЧЕНЬ важно: так запрограммирована голова у 99% людей. И именно поэтому очень часто возникают проблемы при реализации любого проекта. В том числе проекта ИТ. И это свойство разума есть не только в России, но и в Польше, например. Откуда это — особая тема, скажу только, что корни в редукционистском подходе в мышлении, в противовес холистического (целостного) подхода.
Чего НЕ дает такая формулировка: очень сложная параметризация цели. Например, на сколько процентов цель достигнута? Или любой иной параметр цели. Приходится скакать от параметров действия (процесса) к параметрам объекта.
Корректнее цель формулируется только существительным (можно с прилагательным, указателем свойства). И тут самый прикол: «система ERP» — вовсе не цель проекта. «Время одной продажи» — цель проекта. «Время составления заявки» — цель проекта. Значение целевого параметра «Время одной продажи» = 30 минут. Так проще и легче. Целей может быть много, но если все они выражены через существительные, то начать и ЗАКОНЧИТЬ проект внедрения с успехом — очень просто.
Оценка вариантов, консалтинг, и самое страшное — ТЗ. Можно все придумывать и набивать самому шишки.
Так БЫЛО когда-то, лет так 10 назад. Если же сейчас кто-то заикается о «Разработка технического задания» — то лучше сразу бежать как можно дальше. Причина: давно уже стандартизирован системный подход (в отличие от классического). IEEE software life cycle, там все описано. Логика совсем иная, подход холистический, одновременно в разных аспектах (аспекты по ISO 81346). И там нет ТЗ. От слова «совсем».
Насчет документов проекта: если Исполнитель прислал Заказчику SRS в виде ссылки на документ Гугла, причем на 70% SRS уже заполнен — то это профессионалы. Если сразу создали Карту проекта, План работ, Список документов проекта (main document по ISO 11005), дали доступ к стандартам Исполнителя, в которых написано, как все это заполнять — то можно начинать внедрение с таким Исполнителем. Если приходят, звонят, присылают документы по электронной почте, назначают встречи — то проект скорее всего будет провален или затянут от плана в 10 раз.
Далее, а что там у Заказчика? У Заказчика баланс на каждый день. Есть СТО (причем Стандарты процессов, а не только продуктов!), шеф Заказчика умеет пользоваться облачными сервисами, не печатает документы, в фирме пересылают документацию в налоговую с использованием ЭЦП. И самое главное: у шефа фирмы только один сотовый телефон, причем не iPhone. Тогда есть шанс, что можно внедрить у них информационную систему. Если хотя бы один пункт не выполнен — то будут проблемы и проект не закончим.
Почему так? Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.
От типовой модели организации (из тех же стандартов ISO, модель событийная, потоковая). То есть как именно должны быть построены все бизнес-процессы в фирме из определенной отрасли. Ничего не надо придумывать и даже пытаться понять, как сделано сейчас у Заказчика. Все равно, что бы не придумал Заказчик в своей фирме, все, что придумают 100500 консультантов вместе с Заказчиком, все знакомые этих консультантов, знакомые их знакомых — все это УЖЕ есть, описано, оптимизировано, в виде моделей до уровня «поле такое-то, тип текстовый, 256 символов» в соответствующем стандарте. То есть совершенно до таких деталей, что аж офигеваешь…
Например, периодические процессы производства описаны в стандарте IEC 61512 с деталями организации как технологии, так и архитектуры системы. Например, для проекта по краске мы использовали около 15% возможностей, там описанных. И этого хватило для всех технологов и «манагаров» и экономистов, и бухгалтеров, и директоров всех уровней. Были ОЧЕНЬ рады, что рецептуры теперь совсем иначе делаются, намного проще, удобнее, и быстрее. Время создания комплекта документов сократилось с 240 до 40 (!!) нормочасов. И это только применение стандартных ПРОЦЕССОВ! Как эти процессы соединить между собой — тоже все уже описано и стандартизировано в виде best practice. И на основании типовых схем собираем цепочку для получения нужного продукта. Какого? А тут полная воля для Заказчика и для всех его “манагаров”. Любого продукта. Но по стандартным процессам!
Нужно ERP подключить? Очень просто! Стандартная структура фирмы по определенному ISO для конкретной отрасли. Плюс стандартные процессы по тем же стандартам ISO, плюс стандартные желания и требования Заказчика (которые всегда будут не более, чем 15% от тех же стандартов ISO). И стыкуем по стандартной модели из стандарта IEC 62264. И такт стандарты и готовые модели и рекомендации есть по КАЖДОМУ процессу по каждому элементу бизнес-системы у Заказчика.
Никогда еще мне не пришлось столкнуться, чтобы Заказчик чего-то придумал такого, чего УЖЕ нет в стандарте на какой-то процесс. Поэтому внедрение ERP MRP и подобных систем — тупая рутина, типа как внедрение «текстового редактора» у себя дома.
Не парьтесь! Изучайте системный подход, стандарты типовых ПРОЦЕССОВ из ISO IEC IEEE ANSI EN BS, выкиньте кривые ГОСТы (они устарели лет на 15 минимум), а всех, кто говорит про ТЗ — отправляйте в пешее эротическое путешествие.
Управление безопасностью ISO 27k (27001-27010, и иные),
Это основа для достижения цели.
Правовое регулирование там это примерно 10% успеха.
Техническое регулирование (как часть правового регулирования) — 5%.
Регулирование как форма целенаправленного управляющего воздействия, ориентированного на поддержание равновесия в управляемом объекте и на его развитие посредством введения в него регуляторов (норм, правил, целей, связей) — уже лучше.
Остальные элементы управления безопасностью из упомянутого стандарта не менее важны.
Опять же безопасность ЧЕГО? Процесс, продукт, место расположения (три базовых аспекта).
IOT только лишь интерфейс, соединяющий чего-то с чем-то. Быстро, просто дешево — но в реальном мире это только метод связи. Ничего более.
По-хорошему нужен анализ рисков всей системы, которая нас интересует, как «регуляторов».
Например, можно заморочиться и подключить все устройства через хаб. Или по промышленному стандарту типа CAN. Снаружи не влезть. Изнутри можно скомпрометировать.
Все это простейшие примеры, спецы все знают лучше меня.
Анализировать придется с точки зрения надежности систем, с точки зрения безопасности системы, с точки зрения права, и т. д
Хотя результат предсказуемый: все упрется в человека. Оператора, админа, менеджера и т. п.
Поэтому стоит слабое звено вообще удалить. А технически построить систему на принципах непрерывной логики. Суть: каждый элемент системы работает нестабильно, связь элементов системы также нестабильна. А целевой результат работы системы в целом находится в заданных рамках (более-менее стабилен).
Как-то так.
Подход при регулировании — не системный. А «классический». Поэтому ничего не получится «регулировать». Почему?
А очень просто: ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011
«Сложность искусственных систем достигла беспрецедентного уровня. Это открыло новые возможности и вместе с тем привело к усложнению проблем для организаций, которые создают и используют такие системы. „
Проще говоря: системы стали настолько сложными, что понять их стало невозможно. Даже частично, даже “в общем». От слова «совсем никак». Но есть методы как проектировать или анализировать такие системы. И да, так и пришли к «системному подходу».
Перестроить мозги на системный подход — сложно, а иногда и невозможно. Прикол: у некоторых людей изменение архетипов при таком процессе приводят просто к потере сознания и амнезии последних 5-10 минут общения. И это не один случай, а уже много (в моем личном опыте).
Поэтому не парьтесь! Юристы и законодатели все равно ничего сделать не смогут. Все упрется снова в программистов. Что, собственно, и происходит уже не один год.
Ну вводят какие-то методы регуляции чего-то там в Инете. Ну влияют они на 100500 человек. Все в пределах погрешности работы сложной системы.
Ну и прикол напоследок: спросите у знакомых, какова цель школы или института? Все ответят в одном стиле: сказуемое + подлежащее. «Получение знаний», например. Цель бизнеса? «Получение прибыли». Цель регулирования? «Борьба с экстремизмом».
Тут и самое страшное: цель соединена с действием. Цель школы — «знания». Цель бизнеса — «прибыль» или «стоимость компании». Только тогда можно что-то померять (значение параметра). Параметр — только существительное!!!
Цель регулирования?… Вот-вот, фиг сформулируете…
Учим матчасть!
Системный подход — построен, связан с холистическим подходом. Один из вариантов реализации холистического подхода. Примерно так.
В том и фишка, что в разных аспектах всегда будет разное понимание.
И все они правильные. Разные понимания дополняют друг друга, хотя могут частично противоречить. И да, конечно же разные люди иначе понимают и подразумевают значения этих слов. Есть что-то общее — его и ищем и применяем. А разное — игнорируем или просто перекладываем на приоритет ниже. Потом типа согласуем.
«словосочетания «классический подход»»
Я использовал их, потому, что более-менее так они обозначены, например, в книге Wasim — Standards for engineering design and manufacturing. 2006.
Резюме по этой книге тут https://drive.google.com/open?id=1qYp257bZadYd_2sN3hHwWNSF7l0u8PmsTVHXKQxdHw8
Термины за 10 лет устоялись, но в разной среде — по разному.
Для ученых — это нечто странное.
Для инженеров — рутина, «а как же может быть иначе?», особенно в электротехнике. Пример: ePlan.
Для программистов — на уровне архитектуры программ, принципов программирования — тоже само собой разумеется.
Для программистов на уровне управления проектом — уже не так очевидно и понятно.
Для менеджеров проектов — ежедневная рутина, но часто без понимания принципов. Типа «так шеф
сказал делать.»
Для финансистов при до-финансировании проектов в Европе — это бардак из набора стандартных документов, криво и косо составленных. Потому, что в голове каша из двух подходов.
Для производителей еды — это просто требования HACCP, в 90% случаев — отношение «какие-то бумажки снова делать...»
Для иного производства — это система ISO 9000. Опять же, «непонятная фигня, но делать бумажки приходится...»
Так что в разных группах — очень по-разному отношение и понимание.
Хотя, с другой стороны, мнение ВСЕХ, кто «не понимает» или кому лень разбираться — не играет никакого значения. Согласен или не согласен, понял или не понял — все равно будешь применять именно системный подход. Вопрос только времени и положения.
Понял — делаешь быстро и работаешь шефом. Не понял — делаешь медленно и работаешь исполнителем.
Кстати, разница в производительности катастрофическая: один и тот же документ для финансирования проекта делается за 40 нормочасов или за 270 нормочасов.
40 — если понимаешь системный подход. 270 — если нет. Отсюда и уровень оплаты, ведь платят за результат, и сумма — одинаковая в обеих случаях. Поэтому приходится учить матчасть.
Как-то так.
Метафора из геометрии: есть в трехмерке цилиндр. Правый вид (проекция) на плоскость — это прямоугольник. Вид сверху (тоже проекция) — окружность. Это «аспекты» из ISO 81346. То, что видим с определенной точки зрения. Методы редукционизма (классические): видим одну проекцию.
Говорим только о ней. Модель одна, стремимся к точности, полноте, непротиворечивости. Классификация — линейная, двумерная, иерархическая. Объект «состоит из» частей. Есть конкурирующие точки зрения, один говорит «прямоугольник», другой — «нет, круг». Методы — дискуссия, «в споре рождается истина» и т. п.
Холистический подход: (системный). Видим одну проекцию, но всегда учитываем, что есть еще иные проекции. Говорим об одной проекции, потом о другой, потом от третьей. Только все проекции (модели) вместе и одновременно дают представление об цилиндре. Моделей множество, нет целей получить точные, непротиворечивые и своевременные модели. Классификация параллельно в нескольких аспектах (трехмерная), не иерархическая, аддитивная. В объекте можно выделить части в определенном аспекте. Но это не значит, что есть только эти части! Всегда есть целость, всегда выделение частей неточное, неполное. И поведение частей это одно. А поведение целости — это нечто иное. Точки зрения (модели) дополняют друг друга, хотя могут быть противоположными по смыслу, могут частично совпадать, могут противоречить одна другой. Методы: обсуждение только общих частей моделей, поиск совместного видения целого, дискуссии запрещены принципиально. Пример: если в документе что-то сильно не так, с точки зрения редактора, то делается форк документа (новая версия), а не ищется консенсус.
Это коротко про подходы. Системный подход — часть холистического мировоззрения.
Материалы у меня есть, если интересно — пишите на майл vb@in-genium.in, включу доступ (всегда бесплатно, то есть даром). Это моя библиотека (сайт на G Suite), там куча стандартов ИСО, поэтому доступ не открытый :-)
Ну и напоследок: с 2008 года системный подход внедрен ВЕЗДЕ на уровне стандартов деятельности (процессов, а не только продуктов). Поэтому применять придется, хотим того или нет. Ни вашего, ни моего желания никто не спрашивает. И да, все именно так. Если нужны примеры — то все покажу и обосную. Для каждой отрасли, для каждого вида деятельности.
ВСЕ такие стандарты построены по одному принципу (Цикл Деминга, PDCA).
цикл «планирование-действие-проверка-корректировка» Обратите внимание: ключевое слово — цикл!
Главная проблема внедрения этих стандартов (по моему личному опыту в России и Польше) четко сформулирована много лет назад Чеховым: «Дело не в пессимизме и не в оптимизме, а в том, что у девяноста девяти из ста нет ума. „
Для начала: на концептуальному уровне, на уровне архитектуры системы и и даже на уровне “use-case» ничего придумывать и разрабатывать не надо. Все уже есть. на 90% все уже есть в виде типовых решений на уровне приложений и протоколов. И даже на уровне кода и программ есть все нужное на 60-70% для всех видов элементов системы.
Проблема острейшая на уровне управления проектами по конкретному изделию.
Не читают стандартов. Не планируют. Пытаются что-то делать, тратят 90% времени. На проверку и корректировку уже нет ни сил ни времени. Очень коротко так выглядит этот балаган.
Основная причина нетривиальная: многие люди применяют «классический» подход к деятельности. Также известный, как «редукционизм».
А большинство стандартов, готовых продуктов, протоколов, программ, документов, принципов работы, методов сертификации — построены на системном подходе. Также известен, как «холистический подход».
Вроде бы некая сугубо научная ботва, ну что такого? А результат страшный: базовая логика в этих подходах разная. Что приводит к тому, что инженер тупо не понимает, о чем вообще речь? Типовая реакция: «Че за фигня, зачем писать кучу бумажек?? Когда работать-то будем??»
А на уровне законодателей вообще полный привет. Они обычно даже на банкетах умом не блещут, а уж в общей теории систем там вообще конь не валялся…
Возможное направление развития только на уровне техники и технологии (код, протоколы, железо). А людишки подтянутся… То есть все законодательные инициативы — малоэффективны в сравнении с усовершенствованием Управления Проектами в конкретной фирме.
Предлагаю еще сильнее обострить в этом направлении.
Очень важным, мне кажется, будет ответ на вопрос: может ли существовать и применяться криптовалюта вообще без легитимизации в юридическом аспекте? Нужен ли вообще юридический аспект при построении моделей отношений с использованием крипто-технологий?
Из всего, что пока я понимаю — ответ отрицательный. Крипто системам не нужна легитимизация в традиционном праве. Совсем не нужна. А все потенциальные и реальные проблемы при транзакциях можно решить ТЕХНИЧЕСКИМИ методами. Более обидно: крипто-системе глубоко по-фигу на мнения или чаяния юридической системы.
Можно посмотреть с такой точки зрения:
Крипто-технологии, крипто-валюты — это отдельный слой реализации протокола взаимодействия между субъектами. По аналогии со слоями (и принципами) OSI, на которых построена коммуникация Инета.
С этой точки зрения, традиционное право — только один из слоев такого взаимодействия.
Крипто-слой в этой модели — параллельный слой для слоя традиционного права.
В крипто-слое реализованы ВСЕ функции, протоколы слоя традиционного права.
Основа использования традиционного права, как защитного механизма, построена на нескольких допущениях:
1. При отношениях (транзакции) может возникнуть конфликт.
2. Множество слабых людей могут победить одного очень сильного. Можно иначе: большая и сильнейшая система побеждает меньшую и слабейшую. Система, у которой больше элементов и более совершенные связи считается более сильной. Это если рассматривать право с точки зрения теории систем (упрощенно).
3. Элементы системы (субъекты) в системе права соединяются едиными законами.
Есть и иные допущения, но пока они не рассматриваются.
Все эти функции реализованы так или иначе, криво или не очень в имеющихся крипто-протоколах, крипто-валютах.
Может ли быть интерфейс между слоями крипто и традиционного права? Может быть. А может и не быть. Это как будут себя вести юристы. Вопрос за 2 года встал по иному: если юристы почешутся, то крипто-технологии обратят на них внимание и будут сотрудничать. Если нет — идите лесом… Да, именно так остро. Все просто: смотрите на инвестиции в эту область: финтех — 5 — 15 — 75 млрд баксов. Динамика за 3 последних года. И это только часть крипто-технологий.
И что самое веселое: если технологии финтех первыми внедрят банки — то государство лишится функции на эмиссию денег. Совсем лишится. Будет только сторожевым псом определенной территории. А это — на 90% трандец амбициям всех «групп интересов».
Если же технологии финтех первым внедрит государство — то банки лишаться функции клиринга и платежей. То же на 90% трандец амбициям шефов банков.
Так что веселье только начинается. Устраиваемся поудобнее и радуемся!
PS
Насчет интерпретации криптовалюты в рамках юридической системы. Криптовалюта — нематериальный актив. Набор ОТКРЫТОЙ информации, которая имеет ценность для владельца. https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BC%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D1%8B
«использование в течение длительного времени» и «компания не предполагает последующую перепродажу данного имущества в течение 12 месяцев» обходятся очень просто, а все остальное — подходит.
Тогда все операции — договор мены. И тут начинается супер-веселье…
Пишем код, а не кодексы… А юристы — потом подтянутся…
А еще — взрывчатыми веществами. Может быть контроль ВВ сделать на основе специальных датчиков? Они есть.
А еще — пользуются глупостью людей. Может быть повысить уровень образования? Пропаганды?
А еще — они едят еду. Может быть отравить всю еду, чтобы они просрались? :-)
Стойкое шифрование известно уж много лет. Технически его применение никак не ограничить.
Поздновато пить боржоми, почки уже отвалились.
Да, можно запретить дуть ветру. И что? Выполнить такой запрет можно только технически, не административно.
Ну и насчет агитации, вербовки и т. п… Специалисты знают как с этим бороться, и каналы вербовки не очень важны. Если кто-то где-то что-то заявляет о важности отключения шифрования — то это плохие специалисты. Оценивайте именно так.
Все верно. Вы правы. Кто-то кого-то должен защищать. В фантазиях — это так. В реальной жизни — нет.
Никто не защитит Вас от самого себя. А прежде всего, 90% всех проблем в онлайне — от личной глупости. Или от чувства собственной значимости.
Например, клевета. Если меня не интересует мнение других людей — то клевета на меня невозможна. То есть это по сути мое отношение к реальности, причем тут государство?
То же самое про право на забвения в Инете. Оно не нужно, если меня лично устраивает полная открытость и полная информация обо мне. Если Вам такая открытость неприятна, то решения два: сменить свою оценку события. Или найти техническое решение, чтобы на Вас открытость не влияла. Опять же, это только Ваша квалификация и знания. Не знаете как сделать? Учите матчасть. Зачем снова надеяться на кого-то? На государство, на админов и т. п. Да, раньше так было сделать проще.
Типа поручить профессионалу заботу о себе любимом. Но за 200 лет кое-что изменилось, если Вы заметили. Государство теперь, это просто большая корпорация с несколькими группами интересов. И ни Вы, ни я, ни еще 100500 обычных людей не входят в эти группы интереса. Так что зачем пытаться использовать старые методы? Они перестали быть эффективными. Есть иные методы. Да, они сложнее. И что? Компьютер тоже стал сложнее за последние 20 лет. Это же никого не беспокоит.
Мне кажется, что путь совсем иной: не пытаться использовать старые социальные методы, типа государства. А использовать новые методы, например на основе блокчейн. Много идей есть у Джима Белла. Много есть в системах на основе smart contract. Много можно использовать методов из социальной психологии в связке с ФБ и социальными сетями. Так что государство (или подобные структуры) тут не причем.
Идея прелестная! Хотя есть одна трудность: ни читают. Написать-то можно. Точнее, может кто-то и прочитает. Но мало кто поймет хоть что-то. Поэтому не будет никакой реакции.
Причина простая: низкая квалификация.
Хотя, по сути, проблема «электронных денег», «криптовалюты» в рамках права представляет небольшой интерес. С одной стороны: среда обращения — иная реальность, параллельное правовое поле. Так что просто по-фигу, лично мне. Все потуги что-то регулировать упрутся в техническую сторону. А ее не решат, потому, что — низкая квалификация (см. выше).
С другой стороны, сам объект не существует. От слова совсем. В материальном виде «цифровых денег» нет. Отсюда интересный вывод: в МОДЕЛИ реальности (интерпретация цифровых денег, как информационного объекта) можно придать ОБРАЗУ любое значение. В том числе, и переменное значение. Разные аспекты объекта могут существовать одновременно. По простому — как хочу, так и кручу. Например, «цифровые деньги» просто текст. Мне нравится читать на этом языке, и ничего иного он не значит. Или «цифровые деньги» — это нематериальный актив. Типа программы. Тогда меняем один актив на другой. Причем тут оценка? Договор мены — непростая позиция. Особенно, если привязать фактор времени. Сколько стоил биткойн? А сколько сейчас? А как измерять ценность кода? А если кодом одного биткойна зашифровали мое любимое фото, и я готов отдать за этот КЛЮЧ к расшифровке 100500 баксов? Я ведь нарисую тогда любую справку, проведу 1500 экспертиз государственных, и все они подтвердят ЦЕННОСТЬ, важность, значимость именно этого кода для меня. Так что чудить можно по-тяжелому.
Мы когда-то так чудили с «мусорными» векселями. Они стоили 5% от номинала. А списать можно было полный номинал в затраты. Почему? Потому, что так на нем написано. И ничего не смогли сделать налоговики. Тут же вариантов еще больше.
Но зачем все это? Проще вообще уйти полностью в параллельное правовое поле. Тем более, что Джим Белл еще в 1990 году придумал, как исчезнут все политики, правители и законодатели. Тогда это было ТЕХНИЧЕСКИ невозможно реализовать, хотя ЭКОНОМИЧЕСКИ — все было супер! А теперь есть возможность технической реализации его идей Assasins Politics. Так что правители вваливают кучу бабла в финтех — будет кирдык банкам. А когда финтех мощно заработает (на уровне бытовухи) — то кирдык правителям. Идеи Джима Белла никуда не делись, все известно и доступно. И да, там много тонкостей, много вопросов. Ну и что? Все решаемо…
И сейчас перебираюсь полностью на инструменты гугла. ОТ использования продуктов микрософт отказался почти полностью.
С точки зрения системологии и инженерии продукты (сервисы) гугла построены оптимально.
Мне нужна система для лабораторного журнала при разработке сложной химической продукции — за 2-3 часа я сделал такую систему и тоже на таблицах Гугла. Специализированные решения от Agilent и иных *удаков имеют меньший функционал и крайне неудобны в работе.
Управление проектами уровня 2-3 млн рублей, государственное дофинансирование R&D работ 5-10 млн рублей, технические проекты уровня предприятия (5-10 млн рублей) — все прекрасно реализуется на GSuite.
Это с точки зрения бизнес-процессов. Инструмент модульный, простой, оптимальный.
В Аспекте работы командой или одиночкой: сначала есть таблицы и документы, делай сам. Потом я перешел на корпоративный вариант (платный, по 4 евро на рыло) — инструменты остались те же самые, просто возрос функционал. Читал недавно про более продвинутые планы — тот же подход. Все просто, ясно и шаг за шагом.
Главное — можно работать командой, дистанционно, одновременно. и НЕ НАДО «пердолить осла» с информатиками, чтобы получить такую возможность. Все работает БЕЗ приглашения каких то специалистов и танцов с софтом и железом.
в Аспекте функционала: есть все, что НЕОБХОДИМО. Рюшечки — можно допилить. Кстати, я вчера задумался (пока этап анализ идеи) над программой, которая бы реализовала систему MRP и остальной учетный функционал типа 1С, только на инструментах гугла. Не бух учет! А именно контролинг! В виде открытой платформы, модульной, причем со встроенными системами работы с технологиями финтех (блокчейн, DAO). Было бы очень прикольно нужно.
в Аспекте программирования:
основа — nonSQL базы данных. Что еще нужно лучше? А что ЕСТЬ реально лучше?
проблемы масштабирования решаются модернизацией инструмента до более высокой версии. Гугл, если что, вроде работает, как система, с немаленькой нагрузкой…
фреймворки для архитектуры — все есть
языки — какие не лень, те и применяй
работа на таблетах и телефонах — вроде как реализовано.
более-менее все стандартизировано — да.
система безопасности — тоже есть. Вопрос тут спорный, но есть простой критерий: проведите аудит своей локальной системы на том же уровне, что гугл — тогда можно сравнивать, кто лучше.
Как-то так…
Еще раз, огромное спасибо!
Хотел бы немного с иной точки зрения посмотреть на биткойн.
Есть «слой» реальности, где действует право. Например, те или иные законы в России.
Есть «слой» в котором работают биткойны.
Предлагаю не смешивать эти «слои» и не пытаться применять к биткойнам правила права.
Да, могут быть интерфейсы между «слоями». Но пытаться притянуть правила одного мира в другой мир?
Да и не зачем этого делать. Может быть иная позиция: мне, как пользователю биткойна и технологий блокчейн нет никакого дела до государства и до права. Пусть чудят в своем слое как хотят. Просто игнор. Собака лает — ветер носит. И это реально.
А вот интерфейс между этими слоями — это иное дело. Он может быть сетевым, хаотически возникающим и пропадающим. Можно использовать дырки в законах и доводить из до абсурда, для целей работы этого интерфейса. Как такой вариант?
Такой подход — только один из возможных. Есть иные подходы для решения задач безопасности систем. Например, давно уже используются методы выявления и коррекции неисправностей элементов систем на основе непрерывной логики. Занимались этим В.И. Левин и компания.
Главное: можно построить надежную систему из неправильно работающих элементов. Причем ВСЕ элементы могут работать неправильно, по случайным законам («глючить»). Но система в целости будет всегда давать правильный результат. Лишь бы хоть как-то работала.
Поэтому проектирование электроники в российских реалиях может быть построено на иных принципах:
1. Покупаем самый ненадежный китайский отстой, старый хлам и вообще не морочимся ни на качестве, ни на «закладках» в элементах. Цена за процессоры и иные элементы будет по 1 баксу за ведро. Какие? А хотя бы Espressif Systems системы типа ESP8266 или AllWinner, в общем самого низкого ценового диапазона.
2. Проектируем системы на основе принципов непрерывной логики (и им подобных, сейчас много есть иных вариантов) из этого хлама. Хотя как посмотреть: ESP32 в количестве 1000 штук спокойно заменят Elbrus-4.
3. Пихаем в эти системы оригинальный софт, уже свой собственный. Но делаем его корректно, красиво, правильно!
4. Архитектура систем и софт как раз и будут направлены на то, чтобы из принципиально нестабильных элементов получить правильно и стабильно работающую систему.
5. Применяем этот же подход не только к электронике, но и к политике.
Радуемся!
Немного выйду за пределы программирования.
При анализе в любом проекте столкнулся именно с проблемой мифологичного сознания.
Ученые, разработчики, аналитики, причем неплохого уровня уверены, что в материальном мире есть объекты, частицы, «черные дыры» и т. п. И это серьезная проблема!
Они уверены, что модели в мифологическом сознании есть в реальности!
Достучаться до них очень сложно!
Очень помогает стандарт ISO 81346, но только для технических специалистов.
У ученых, физиков, химиков такая каша в голове, что просто дым и чад.
Я сам столкнулся с проблемой вменяемой информации на темы объектно-ориентированного мышления.
Если есть какие-то ресурсы — просьба поделиться.