Еще как зависит. Любая криптография ломается терморектальным криптоанализом, вне зависимости от длины ключа и стойкости алгоритма шифрования. И если ТК можно практиковать в какой-либо стране (например, США), пускай и в лайт-версии в виде полиграфа с перебором символов, то ее и будут практиковать. В странах демократических, например, в Швейцарии, или европейских карликах, да, будет работать.
1. Я про другое. Как проверить, что кнопки нажимал именно Вася Пупкин, а не его жена, сосед,… Ну или злоумышленник, укравший ключ и выдающий себя за Васю?
2,3 это как? К каждому столбу мента по поставишь.
4. Я как раз про клиентское устройство. И тут, увы, оба возможных решения плохие:
4а: как в сберовском приложении: если обнаружены признаки небезопасности, операции невозможны. Т.е. избирателю отказывается в праве голоса. Что противоречит принципам демократии.
4б. отдельное устройство. А значит, отдельные деньги на гаджет, который более ни на что не пригоден. И кто может гарантировать, что там нет заложенных государством бэкдоров? Как известно, в миллиардах строк кода легко прячутся десятилетиями любые баги, несмотря на открытость исходников.
Резюмируя, проблема организации электронного голосования не имеет никакого отношения к ИТ, криптографии, и т.п… Вообще никакого. По одной простой причине — из системы невозможно исключить слабое звено в лице избирателя.
Следствие: в демократическом обществе 100%-но электронного голосования быть не может, если все члены общества не знают друг друга в лицо и 100%-но доверяют друг другу.
1. А как проверить, что голосовал именно тот человек? Как сопоставить живого человека и ключ?
2. Как проверить, что человек проголосовал добровольно, и никто рядом с ним не стоял во время голосования с автоматом? Т.е. что оно было действительно тайным и добровольным?
3. Как отфильтровать после голосования тех, кого заставили проголосовать, от тех, кто во время очередного обострения волшебные таблетки от галюцинаций и голосов в голове принять забыл?
4. Как гарантировать отсутствие заразы на клиентском терминале (комп, телефон, умные часы, etc), которая «проголосует» как надо? (допустим, в варианте, когда избиратель забыл проголосовать?
5. Проверка правильности подсчета в случае теракта в датацентре.
DQ в MDM все-таки в зачаточном состоянии, у того же САПа или Информатики рекомендуется использовать для этих целей отдельное ПО.
Если модель данных часто меняется, то видимо надо где-то посмотреть и понять, почему так происходит. Все-таки мы ведем условно-постоянные данные, если про MDM говорим. На одним из моих недавних проектов (достаточно крупная международная компания, в первой тройке на рынке) добавление новых полей происходило с частотой 2-3 поля в год по всем управляемым объектам, включая транзакционные данные. И связано было с расширением функционала.
Ну если для вас проводить обследование значит поверить заказчику на слово («дом из круглых кирпичей»), а не вникать в суть проблемы («нужен дом без углов в соответствии с принципами феншуя»), то кто ж виноват в этом? Хотя чем крупнее компания-внедренец, тем чаще именно так и происходит.
С тем, что по всем вариантам надо детально и на пальцах показывать возможные последствия, думаю никто не будет спорить.
Какие именно средства?
Workflow? он везде
DQ — так это и в MDM в зачаточном состоянии, есть отдельные продукты
Кастомизация — ну тут вообще зоопарк решений.
Проверка на дубликатов — настраивается.
Механизмы консолидации и т.п. — в данном решении не использовались.
На мой взгляд, правильнее было идти от процесса, а не от систем. Определить задачи, нереализуемые в текущем ландшафте, посмотреть, как из реализовать в имеющемся софте, а уж потом принимать решение — глубокая доработка либо внедрение MDM.
Часто доработать тот же SAP ERP проще и дешевле, чем внедрять MDM.
Если же целью было создание демо-стенда, то лучше было подобрать более релевантный сценарий.
Если в системном ландшафте только ERP и CRM, и между ними есть интеграция, то можно было выстроить процессы и потоки данных так, чтобы единой точкой ввода для данных о контрагентах был CRM. А процессы согласования и там можно настроить. Без внедрения MDM.
В вашем же варианте, количество систем увеличилось без особой необходимости. Да, продали MDM, молодцы. Это и было целью?
P.S.Это в случае, если CRM нормальный, а не студенческая поделка. Если же функционал CRM убогий, то получается ситуация, что клиент ССЗБ, сэкономив на CRM получил в нагрузку более дорогой продукт. Насколько я помню, практически у всех вендоров MDM лицензии одни из самых дорогих.
По крайней мере, в SAP, есть возможность применения более широких аналитик по контрагентам (BP) и ведения разного рода отношений. Хоть все склады, куда отгружать, заводи. Привязка через роли БП осуществляется. Так что проблема надуманная, и связана скорее всего с тем, что ERP выбиралась без учета реальных потребностей бизнеса, либо настроена перректально.
2,3 это как? К каждому столбу мента по поставишь.
4. Я как раз про клиентское устройство. И тут, увы, оба возможных решения плохие:
4а: как в сберовском приложении: если обнаружены признаки небезопасности, операции невозможны. Т.е. избирателю отказывается в праве голоса. Что противоречит принципам демократии.
4б. отдельное устройство. А значит, отдельные деньги на гаджет, который более ни на что не пригоден. И кто может гарантировать, что там нет заложенных государством бэкдоров? Как известно, в миллиардах строк кода легко прячутся десятилетиями любые баги, несмотря на открытость исходников.
Резюмируя, проблема организации электронного голосования не имеет никакого отношения к ИТ, криптографии, и т.п… Вообще никакого. По одной простой причине — из системы невозможно исключить слабое звено в лице избирателя.
Следствие: в демократическом обществе 100%-но электронного голосования быть не может, если все члены общества не знают друг друга в лицо и 100%-но доверяют друг другу.
2. Как проверить, что человек проголосовал добровольно, и никто рядом с ним не стоял во время голосования с автоматом? Т.е. что оно было действительно тайным и добровольным?
3. Как отфильтровать после голосования тех, кого заставили проголосовать, от тех, кто во время очередного обострения волшебные таблетки от галюцинаций и голосов в голове принять забыл?
4. Как гарантировать отсутствие заразы на клиентском терминале (комп, телефон, умные часы, etc), которая «проголосует» как надо? (допустим, в варианте, когда избиратель забыл проголосовать?
5. Проверка правильности подсчета в случае теракта в датацентре.
Если модель данных часто меняется, то видимо надо где-то посмотреть и понять, почему так происходит. Все-таки мы ведем условно-постоянные данные, если про MDM говорим. На одним из моих недавних проектов (достаточно крупная международная компания, в первой тройке на рынке) добавление новых полей происходило с частотой 2-3 поля в год по всем управляемым объектам, включая транзакционные данные. И связано было с расширением функционала.
С тем, что по всем вариантам надо детально и на пальцах показывать возможные последствия, думаю никто не будет спорить.
Workflow? он везде
DQ — так это и в MDM в зачаточном состоянии, есть отдельные продукты
Кастомизация — ну тут вообще зоопарк решений.
Проверка на дубликатов — настраивается.
Механизмы консолидации и т.п. — в данном решении не использовались.
На мой взгляд, правильнее было идти от процесса, а не от систем. Определить задачи, нереализуемые в текущем ландшафте, посмотреть, как из реализовать в имеющемся софте, а уж потом принимать решение — глубокая доработка либо внедрение MDM.
Часто доработать тот же SAP ERP проще и дешевле, чем внедрять MDM.
Если же целью было создание демо-стенда, то лучше было подобрать более релевантный сценарий.
В вашем же варианте, количество систем увеличилось без особой необходимости. Да, продали MDM, молодцы. Это и было целью?
P.S.Это в случае, если CRM нормальный, а не студенческая поделка. Если же функционал CRM убогий, то получается ситуация, что клиент ССЗБ, сэкономив на CRM получил в нагрузку более дорогой продукт. Насколько я помню, практически у всех вендоров MDM лицензии одни из самых дорогих.