Журнал о системах электронного документооборота (СЭД)
Технологии проектирования и построения СЭД

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

  6 комментариев Добавить в закладки

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

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

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

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

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

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

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

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

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

Ещё материалы автора
Похожие записи
Комментарии (6)
Михаил Романов 03 июня 2013 г. 08:46  

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

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

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

Вячеслав Лазарев 03 июня 2013 г. 08:48  

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

Елена Романченко 12 июня 2013 г. 08:30  

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

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

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

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

Валентина Писанова 13 июня 2013 г. 12:17  

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

Вячеслав Лазарев 13 июня 2013 г. 12:28  

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

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

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

Александр Сидоренков 14 июня 2013 г. 16:17  

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

Сейчас обсуждают
Больше комментариев