Практика, позволяющая системам учитывать человеческую ошибку?

Question

В системах иногда приходится учитывать возможность получения реальных данных. Учтите, что некоторые данные поступают с бумажных форм. А формы по своей сути имеют ограниченные средства проверки данных.

Пример 1. В одной форме пользователи должны вводить целое расстояние (в милях) в пробел. Мы собираем информацию в виде строки, поскольку не всегда получаем целочисленные значения.

Пример 2. В другой форме мы фиксируем код. Этот код должен отображаться на один из кодов в нашей системе. Однако иногда код, написанный на форме, неверен. Мы фиксируем код и позволяем ему существовать с недопустимым значением до некоторого будущего времени разрешения. То есть мы временно разрешаем неверные данные, поскольку важно записать запись, даже если какая-то ее часть недействительна.

Мне интересно узнать больше о том, как системы принимают неверные данные, то есть человеческие ошибки. Предполагается, что базы данных являются оплотом целостности данных, но реальный мир запутан и люди делают ошибки. Системы должны позволять нам отражать эти ошибки.

Каким образом разработанные вами системы учитывают человеческую ошибку? Какие практики вы использовали? Какие уроки вы выучили?

Любое дальнейшее чтение по теме? (У меня были проблемы с поиском в Google.)

Answer 1

Я согласен с вами, что бы мы ни делали, нет гарантии, что мы сможем избавиться от плохих или неверных данных. Особенно, но не только, если речь идет о пользовательском вводе. По моему опыту, такие же проблемы существуют в сложных интеграционных проектах, в которых вам приходится интегрировать и объединять (часто противоречивые) данные, полученные из разных систем.

Хорошая стратегия состоит в том, чтобы отделить вход от самой операционной системы. Во-первых, поместите предоставленные пользователем (или внешнюю систему) данные в отдельное хранилище данных (например, в другую схему). На втором этапе загрузите эти данные в оперативное хранилище данных, но только в том случае, если это соответствует строгим правилам (например, используйте программное обеспечение для проверки адреса для проверки данного адреса). Такой подход извлечения, преобразования, загрузки (ETL) довольно распространен в решениях хранилищ данных (DWH), но может быть применен программно и в транзакционных системах (по моему опыту).

Приведенный выше подход часто приводит к асинхронным процессам, в которых входные данные подставляются первыми и (возможно) в более позднее время внешняя сущность (пользователь или система) получает обратную связь, независимо от того, правильны ли ее данные.

РЕДАКТИРОВАТЬ: Для дальнейшего чтения я рекомендую взглянуть на концепции DWH. Хотя, возможно, вы не захотите создавать такую ​​вещь, вы можете частично применить эти концепции:

http://en.wikipedia.org/wiki/Extract,_transform,_load

http://en.wikipedia.org/wiki/Data_warehouse

http://en.wikipedia.org/wiki/Data_cleansing

Answer 2

Государственный департамент, в котором я работал, проводит множество опросов, большинство из которых (были) все еще основаны на бумаге.

• Все результаты были OCR'd в систему.
• В рамках процесса распознавания сохраняется цифровое сканирование форм.
• Затем данные проверяются, данные, которые невозможно расшифровать или которые не проходят проверку, помечаются.
• Когда оператор-человек просматривает цифровые данные, он может изменить данные, если они уверены, что они могут правильно интерпретировать то, что код не мог; они (вот это круто) также могут вызвать сканирование бумажного оригинала и использовать его для определения того, что пользователь пытался сказать.

В другой теме ; в какой-то момент вы хотите проверить данные, поступающие по всем ожидаемым диапазонам данных, которым вы хотите, чтобы они соответствовали; покупая отклонение в точке входа, вы даете пользователю возможность исправить это - компромисс состоит в том, что каждый раз, когда вы отклоняете его, вы увеличиваете вероятность того, что он откажется от всего процесса.

В какой-то момент в вашей системе вам нужно указать правила, которые будут использоваться для проверки. В конце концов система станет такой же умной, как эти правила. Вы можете сами разработать их в коде (возможно, в бизнес-логике) или использовать сторонний компонент.

иметь гибкий контроль над проверкой очень важно, так как они могут меняться со временем.

Answer 3

Если честно, переход от бумажных систем к ИТ состоит в том, чтобы устранить эти ошибки и убедиться, что все данные всегда верны.Я сомневаюсь, что любая правильно спланированная и разработанная ИТ-система (особенно бизнес-финансовые системы) допускает такие ошибки.В любом случае, я не работаю в компании ...

Answer 4

Я начал работать в правовых системах еще до эры ПК.В базах поддержки судебных процессов обычно необходимо размещать фактически неверную, неполную и противоречивую информацию.Требуется другой способ мышления.

Короткая версия.,.

Вместо записи одного факта вы записываете несколько утверждений о факте.Все сводится к созданию базы данных для хранения данных из таких утверждений.

• В интервью 2011-01-03 08:13 Нил Раймс сказал сотруднику Cane, что он был дома с 2011 года.01-02 20:00 до 2011-01-03 08: 13.
• В интервью 2011-01-03 08:25 Лиза Неверс рассказала сотруднику Cane, что Нил Раймс вернулся домой в 2011-01-02 23: 45.
• В показаниях 2011-05-13 10:22 Коди Максон сказал адвокату Курту Шлагелю, что он видел Нила Раймса в Крогере в 2011-01-03 03: 00

Answer 5

Самое простое, что нужно сделать, - это (это не всегда возможно) разработать интерфейс, в котором пользователи вводят данные, чтобы максимально ограничить объем текста, который им необходимо ввести.По моему опыту, это, кажется, откуда много проблем.Один простой пример этого - предоставить поле выбора или поле автозаполнения

. Единственное, что вы можете сделать, - это сделать все возможное, чтобы определить, верны ли данные, прежде чем войти в базу данных.Я стараюсь дать пользователю, вводящему данные, как можно больше отзывов, чтобы они (в идеале) могли решить некоторые проблемы до того, как данные будут сохранены.Например, это очень быстрая проверка, чтобы определить, имеют ли вводимые данные правильный тип.

Answer 6

Существует множество программных инструментов, предназначенных для решения упомянутых вами проблем. Существуют платформы и инструменты, которые позволяют определять правила очистки и преобразования данных и обработки ошибок проверки. Эти методы широко используются для приложений интеграции данных и бизнес-аналитики. Google для «Качество данных» или «Интеграция данных».