«Больше» - не значит «лучше», определяем поля регистрационной карточки документа

«Юности присущ максимализм,
который максимально проявляется в глупости»
Иосиф Египетский

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

• Поля (интерфейсные элементы для ввода значений) «натыканы» так, что не продохнуть. Их даже не удосуживаются выравнивать по горизонтали и вертикали;
• Порядок расположения полей не соответствует порядку их заполнения. Поля, заполняемые за один сеанс, разбросаны по закладкам и не сгруппированы;
• Отдельные элементы управления (кнопки, поля, закладки и др.) не скрываются, хотя не нужны пользователю на данном этапе обработки документа;
• Размеры полей не соответствуют размерности вносимых данных. Казалось бы, «смешное» замечание, но как не странно, вижу такое довольно часто и это объективно вызывает неудобства. Яркий пример - система банк-клиент крупнейшего в стране финансового учреждения;
• Некоторые поля просто лишние, об этом и пойдет речь в данной статье.

Итак, проектируя решение, некоторые специалисты (особенно этим грешат молодые) идут по пути максимализма (я эту болезнь называю «гигантизм»). На этапе создания технического задания они предлагают Заказчику перечень реквизитов документа «отсюда и до горизонта», который предполагают отразить на РК. Наверное, пытаются продемонстрировать, что деньги уплачены не зря, проектная команда будет работать в поте лица и система будет мощная и функциональная. По факту же мы получаем того самого монстра с десятком закладок и сотнями полей. А потом еще удивляемся, почему система так долго открывает РК. Конечно, многое зависит от архитектуры платформы, политики кэширования данных и т.д., и все же смею предположить, что РК с 5 полям откроется быстрее, чем РК с 500 полями.

На этапе создания технического задания, в части определения полей регистрационных карточек каждого типа документа, я предлагаю исполнителю и клиенту дать самим себе ответ на вопрос «А зачем нам это поле в регистрационной карточке документа?»:

• Реквизит часто используется в поисковых запросах (не путать с полнотекстовым поиском по текстам документов), например регистрационные реквизиты;
• Значение поля влияет на порядок обработки документа (бизнес-логику) или участвует в математических вычислениях, например сумма договора;
• Значение поля влияет на принятие решения, например срочность оплаты счета;
• Значение реквизита используется для напоминаний, уведомлений или контроля, например срок действия договора;
• Реквизит отражается в формах отчетности.

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

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

P.S. Администраторы «своих» систем электронного документооборота, ради эксперимента, сделайте запрос в базе данных на предмет: в скольких регистрационных карточках внесено значение каждого поля. Возможно, получите информацию для размышления.