|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
работаю програмером в ERP ИС-ПРО вер.7.х (БД на MS SQL Server 2005). нередко сталкиваюсь, что ошибки операторов искажают данные, получаемые через отчетную систему (в ис-про встроен FastReport ver.4), а имхо корявая структура БД не позволяет производить нормальный анализ (например в важных для анализа полях не разшенено использовать NULL, что приводит к значениям '1876-12-31 ..' в полях даты). например (в модуле управления персоналом) дату поступления не введут, дату начало стажа в организации, признак пола, или код причины увольнения, код профессии или должности, или оба кода укажут.. да и много еще чего. я обычно делаю анализ данных, ищу ошибки и несоотвествия, расчет проверяю, но реально уже достало. вот наиболее простой пример: отделу кадров нужен отчет по сотрудникам по районам проживания. в БД есть такое поле "район" (а еще поля "улица" "дом" и т.д.) большинство операторов на это забивают, и вводят адрес сразу текстовой строкой в другое поле. причем кто как.., и грамматические ошибки тоже не редкость. ну и чиво мне, парсер писать ? (как ни странно, в БД нет таблицы "справочник районов города") подскажите, как кто поступает в таких случаях ? как вообще заведено обрабатывать такие ситуации и перед начальство как отчитываться, и нужно ли это делать ? ошибки операторов становятся проблемами програмеров или можно лишь указать на них в отчете про программу, а на обработку забить ? сейчас система в стадии внедрения (еще используется вер.4), так что пока это не критично, и полгода точно еще не будет критично. а вот потом хрен его знает :( ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2009, 15:53 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
Если кратко, здесь как минимум две задачи: 1) обеспечить интерфейс, минимизирующий ошибки оператора 2) обеспечить качество данных там, где не стработает пункт 1 по первому пункту - не давать вводить, если не заполнены обязательные поля, данные не соответствуют формату и т.д. Там где возможно, использовать выбор из списка. В общем все это описано в с букварях по проектированию интерфейсов. по второму пункту в 2-х словах не опишешь. если вкратце - использовать парсер с учетом наиболее распространенных ошибок. Плохие данные возвращать вводильщикам пока не научатся вводить правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2009, 16:54 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
darkbird81работаю програмером в ERP ИС-ПРО вер.7.х (БД на MS SQL Server 2005). нередко сталкиваюсь, что ошибки операторов искажают данные, основная задача СУБД - хранение НЕПРОТИВОречивых данных. Если Бизнес-логика находится в СУБД, то за это отвечает проектировщик БД и архитектор Системы. Соответственно с них и спрос. Аналитик должен им подсказать, какие именно ошибки данных считать критичными для бизнеса. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2009, 17:02 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
darkbird81подскажите, как кто поступает в таких случаях ? как вообще заведено обрабатывать такие ситуации и перед начальство как отчитываться, и нужно ли это делать ? ошибки операторов становятся проблемами програмеров или можно лишь указать на них в отчете про программу, а на обработку забить ? Данные - это вопрос бизнеса. Программеров этот вопрос не должен волновать до тех пор он не волнует бизнес. Качество ввода данных может быть обеспечено - ну например всякими констрейнами. Решать самому такие вопросы {без участия бизнеса} я бы не советовал - а вот поднять вопрос на встрече с бизнесом - обязательно. Постарайтесь уточнить у поставщика (наладчика) вашей ERP ИС-ПРО вер.7.х как они рекомендуют обеспечивать качество ввода данных. Обычно есть какието validation(??) ограничения и в GUI. Они могут быть отключены по умолчанию. Во всяком случае вопрос поднятый - очень правильный. Говорите с бизнесом. И не забудьте учить юзеров ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2009, 17:06 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
darkbird81 вот наиболее простой пример: отделу кадров нужен отчет по сотрудникам по районам проживания. в БД есть такое поле "район" (а еще поля "улица" "дом" и т.д.) большинство операторов на это забивают, и вводят адрес сразу текстовой строкой в другое поле. причем кто как.., и грамматические ошибки тоже не редкость. ну и чиво мне, парсер писать ? (как ни странно, в БД нет таблицы "справочник районов города") подскажите, как кто поступает в таких случаях ? как вообще заведено обрабатывать такие ситуации и перед начальство как отчитываться, и нужно ли это делать ? ошибки операторов становятся проблемами програмеров или можно лишь указать на них в отчете про программу, а на обработку забить ? Используйте КЛАДР в качестве справочника адресов или видите свой, а КЛАДР для сверки. Поля страна, регион, типы нас. пунктов и улиц желательно выбирать из списков в программе. Если адрес не разбирается по справочнику, то пишется как есть - строкой (иностранный например) ... увы бизнесу не запретишь. Прогнать адрес через парсер (у нас пакет функций в Oracle) на разбор и типичные ошибки (отсутствует регион, населенный пункт, улица ...) и автоматически сформировать отчетик, служебку начальству или бизнесу на уточнение. У нас проверкой, разбором занимается отдельный человек, он же отвественный за ведение справочника, рассылку и обработку возвратов ... а адреса используются для отчетов, массовой рассылки и в налоговую :) Mr Marmelad Данные - это вопрос бизнеса. Программеров этот вопрос не должен волновать до тех пор он не волнует бизнес. Вцелом верно, но если бы было все так просто... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2009, 22:13 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
ВСК1. да, было бы хорошо )) но увы, интерфейс по вводу данных обеспечиваю не я. это ваяет фирма-производитель, и ИС-ПРО не опенсорс. 2. по пункту два не понял.. как обеспечить качество данных, если я не могу повлиять на их создание ? парсер я имел ввиду только для анализа данных Petro123 бизнес-логика и в БД, и программно реализована. проектировщики и архитекторы вроде то и отвечают за что-то.. но я так понимаю, мое начальство не хочет с них что-то требовать (( Mr Marmelad бизнесс сказал "посадим операторов, пусть всю базу проверяют, это лучше чем в игры резаться" а учить юзеров мне как-бы по должности не положено 4umg посмотрел КЛАДР. немного не то, что нужно (россия, а мне ток харьков нужен). да и из пушки по воробьям... )) натолкнуло на мысль написать свой справочник адресов и добавить его в БД. но хм.. на него ведь должны быть ссылки в таблицах, в которых содержаться данные по кадрам. наверно проще засадить операторов за проверку/ввод данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2009, 10:21 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
darkbird81, под обеспечением качества данных имелось ввиду следующее: раз уж вы не можете повлиять на качество ввода путем вмешательства в интерфейс, то можно попробовать следующее: организационным путем заставить вводить операторов данные по принятому шаблону. данные, которые вы будете загружать в свою систему проверять на соответствие этому шаблону. Все, что не соответствует критериям отбрасывать и выдавать в виде статистических отчетов руководству - "вот смотрите какие @#$% ваши операторы, данные толком ввести не могут". таким образом вы превратите проблему программеров в проблему менеджеров - пускай у них голова болит - нагнуть ли разработчиков насчет исправления интерфейса или заставить операторов вводить правильно. после того как операторов несколько раз заставят данные перебивать они начнут вводить правильно - проверено опытным путем. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 23:22 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
ВСК, То, что вам нужно, называется "data quality", продукты для этого есть у большинства крупных вендоров. Для адресов, имен, дат, телефонов и прочих реквизитов можно попробовать HFLabs (продукт) или DataQ (Excel и SOAP-сервис). Оба умеют из единой адресной строки с ошибками, опечатками и т.д. получать адрес по КЛАДР. Если вы работаете в РФ, пол можно определить по ФИО в среднем в 98% случаев. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2009, 18:56 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
Dmitry Zh, Подробнее и ссылки есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2009, 19:12 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
Petro123Dmitry Zh, Подробнее и ссылки есть? hflabs.ru, dataq.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2009, 20:05 |
|
обработка ошибок операторов
|
|||
---|---|---|---|
#18+
darkbird81наверно проще засадить операторов за проверку/ввод данных.Проще-то проще, только операторы вносят ошибок больше, чем исправляют. Причем после них вообще тяжело что-то понять, данные выглядят очень правдоподобно :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2009, 20:07 |
|
|
start [/forum/topic.php?fid=33&fpage=38&tid=1548535]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 137ms |
0 / 0 |