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

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

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

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

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

Много работы, и все равно будут вопросы от пользователей, которым влом в этом разбираться.

Если кто-то занимался подобной автоматизацией, какой подход вы использовали, и какие вынесли уроки?

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

Много хороших мыслей, интересно читать.

По поводу корректности данных, это вопрос из другой плоскости. Если для данного поля есть 100% объективно верные данные (сумма столбца в таблице), задача вырождается в более простую - отобрать контроль у человека. Вопрос двойного контроля пропал, также исчезла ответственность работника за правильность подсчёта суммы.

Один из подходов - требовать явное действие от человека.
Хочет автоподсчет? Ставит галочку автоподсчет рядом с полем. Хочет вручную? Убирает галочку, пишет свое.
Стоимость имплементации - по галочке на все поля и способность пересчёта любого поля в любой момент (или двойное хранение данных).

Дата: [__/__/_____] [✓]авто

hVostt,

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

Этот робот-субъект редко ошибается, а иногда не знает ответа, поэтому поле остаётся открытым для редактирования человеком, у которого последнее слово.

Усложняет мою конкретную проблему свойство путезависимости (path dependence) при вычислении значений.

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

"Господины акционеры, я тут правильно дату поставила?"

Корректность данных определяется лицом, кому поручена задача ввода данных. Для этого лицу даётся критерии, источники, и т.д. Зато появляется спрос с данного лица.

В условиях моей задачи автоматизации, спрос снизился до "если робот вбил дату, считать корректной по умолчанию, и в случае ошибки винить робота". Снижение ответственности - неизбежное следствие сокращения ручного труда, ИМО.

Когда я пользуюсь калькулятором, я не проверяю ответы на бумаге столбиком, и если выданный мне для работы калькулятор ошибся при делении, это не моя вина.

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

Все без присутствия врача, вне больницы. Это портативное устройство, вживленное в пациента.