Наверх

ECM-Journal обновился!

Если вы ещё не зарегистрированы на сайте, сделайте это прямо сейчас. Если у вас уже есть профиль, то просто обновите пароль.

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 5

Терминологический вопрос:

регистрационная карточка (РК)

это просто метаданные документа или же имеется ввиду аналог "бамажной" регистрационно-контрольной карточки (РКК)?

Это метаданные документа, в РК также могут быть помещены специализированные интерфейсные элементы.

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

Валентина, на двойные стандарты намекаете? :) Ну да, есть такое.

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

Иначе будет то, о чем писал: на первой общедоступной закладке РК, в самом центре, будет лежать огромное поле, назначение которого знает 2 человека и заполняют его раз в год.

Слава, решил "лайки" собрать описывая очевидные вещи? :) Выдай чего-нибудь глубже, ты же можешь.

Чтобы прокомментировать, или зарегистрируйтесь