Проблема борьбы с дубликатами появляется у многих. Очень часто она
усугубляется тем, что вводят одни, а используют другие. И вот тут, всплывает
как раз организация внутренних информационных потоков предприятия. Т.е. если
к примеру, один чел вводит банковские реквизиты в систему, а другой
отправляет на них бабки, то следовательно, последний на себя берет
ответственность за работу первого, но он то наверняка не согласен брать ее
на себя предварительно не проверив ее! Поэтому ответственность за отправку
бабок у них должна быть общая, либо ввод данных первым проверяется вторым с
установкой признака "ОТК", тогда запись с таким признаком переходит в зону
ответственности второго.
А в системе с тех. точки зрения, помимо механизмов контроля нужно всю
критичность в дубляже вынести за рамки системы. Ну введут двух "пупкиных",
ну хоть трех. Система должна позволить спокойно работать с ними, даже если
это один пупкин. Аналитика интересует? Должно складываться? А вот тут,
должен быть механизм консолидации, либо на уровне данных хранения, либо на
уровне отчетной системы (типа проставить у всех пупкиных признак общности,
которого по умолчанию нет).
Мутно изложил, переписывать лень.


Posted via ActualForum NNTP Server 1.3

aagА зачем дергаться, если система все позволяет? Только потом встает вопрос кто будет ставить этот признак общности и сколько времени уйдет, чтобы выловить таких общих и отделить их от похожих. Надеюсь, вы же не думаете, что это должно делаться само собой, автоматически?
А вот вопросы типа, "кто?", "когда?" и т.п. должны ставиться ДО разработки системы. Она должна иметь эти механизмы. А вот кто и когда будет это делать - это организационный вопрос, который должен быть решен до ввода в эксплуатацию. Хотя конечно на практике все наооборот, сначала внедрили, а потом "и кто теперь это будет делать?".
Над данными в любом справочнике должен быть ответственный, который должен организовывать работу людей(работников) с этим справочником: контролировать (операторов ввода), исправлять (контролировать исправляющих), говорить руководству кому (операторов ввода) какая премия и какие штрафы, и за что (по результатам собственного контроля). И он один и только он несет ответственность перед руководством за содержание справочника. Если в другой службе кому-то становится плохо из-за того, что в справочнике сплошные дубли, значит ответственному дают трендюлей за плохую работу (за плохую организацию работы) и заставляют исправить. И это все практически не имеет отношения к системе, она должна позволять сделать все, что нужно делать конкретным ролям в бизнес модели предприятия. А если на предприятии не предусмотрено такого чела, который отвечает за содержание в системе, тогда и содержание будет никаким, но это уже не имеет отношения к системе.
P.S.: Всем и всегда говорю, что данные в системе и система - это абсолютно разные вещи. Компьютер - это всего лишь помощник в автоматизации, но не заменитель ролей.

Да не вопрос! Естессно там, где можно поставить однозначную проверку, то
наверно ее можно и даже нужно поставить. Но так можно поступить не всегда и
не везде. Взять к примеру справочник условных шкафов, у них нет ни ИНН, ни
серийников, ни MAC-адресов, у них ничего идентифицирующего нет, их делают
тонны компаний и конторок. И вот теперь представьте, что в Вашу систему
сыпятся в режиме он-лайн с 10 удаленных точек описания этих шкафов. Естессно
будут дубли - "к бабке не ходи". Тут должен быть орган с функцией "ОТК",
который будет идти следом за вводом описаний и контролировать введенное
описание, что позволит не держать процесс покупки/продажи этих
шкафов(продовать/покупать можно и без этого "штампика ОТК"), и в тоже время
будет держать порядок.
Теперь по порядку: ... про ответственного забыли, но ответственность
осталась, поэтому когда будут искать крайних найдут именно его.
Ошибок ручного ввода не избежать на 100% - согласен на 100%.
Система должна позволять дублирование, и коллизии возникают не у нее, а в
голове у того кто попытается получить от системы какую-либо информацию,
касающуюся задублированных записей. Кстати, есть понятие идентификатор
записи, а есть понятие идентификатор объекта. И в этом смысле система
работает с записями в справочниках, а не с реальными объектами.
Возникающие коллизии будет пытаться решить не система (еще раз подчеркиваю,
что за всем должны стоять люди, системы сами ничего не делают), а те, кому
станет нужно увидеть одного пупкина вместо двух. Вот они и будут при помощи
функционала системы сводит двух пупкиных в одного. Система должна только
предоставить для этого возможность.
Проставление "признаков общности" выливается не в напрасно потраченные
человеко-дни и не в ошибки автоматизации, а в причесывание и поддержание
корректности справочника.
P.S.: Все конечно зависит от назначения справочника. Считаю, что когда
дублирование не критично, то можно обойтись косвенными признаками
дублирования и формальным оповещением на стадии ввода описания, если
критично, то нужно наращивать в системе функционал по борьбе с дубляжом.


Posted via ActualForum NNTP Server 1.3