Аналитик AIIM Ник Геддес (Nick Geddes) подготовил White Papers «Turning Documents into Data - using data capture to improve document processing», где сведена прошлогодняя статистика, касающуюся сканирования и захвата документов, и представлены рассуждения и выводы.

Выделю то, что мне показалось интересным и полезным, представлю пару своих мыслей на тему «белой бумаги».

Как обстояли дела в 2013-ом

Большинство организаций (68%) использовали технологии захвата для создания электронных архивов и включения информации в автоматизированные workflow-процессы. Уровень освоения технологий был у всех разный. Респонденты определяли этот уровень следующим образом:

Если оценивать процент пройденного пути (где цель – избавление от бумаги, а средства – сканирование и захват), распределение организаций выглядело так:

Используя средневзвешенную среднюю, получим, что всем вместе компаниям предстоит пройти еще 83,5% пути.

Иными словами, если опираться на сведенную Ником Геддесом статистику, можно говорить, что потенциал инвестиций в сканирование и распознавание документов, в 4 раза больше текущих средств, вложенных компаниями в захват данных.

В числе топ-5 процессов, автоматизированных с точки зрения захвата данных, были:

●    внутренний HR (затраты, расписания, адаптация) – автоматизирован у 65% организаций;

●    финансы и оплата счетов – у 62%;

●    поддержка и переписка с пользователями – у 61%;

●    специфические направления деятельности – у 61%;

●    договоры и закупки – автоматизированы у 56% организаций.

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

Автоматическая обработка и занесение данных в систему может сократить на 75% скрытые трудозатраты, связанные с ручным вводом данных и прочими подобными процессами.

Исключается человеческий фактор, который подчас приводит к некорректному занесению данных в систему – по итогам автоматизации уровень точности может достигать 99%.

Снижается стоимость обработки на один документ, что приводит к положительному возврату инвестиций (ROI) в автоматизацию захвата.

Доступ к важным данным, автоматически занесенным в ECM- или ERP-систему, ускоряется в разы – процессы, завязанные на документах, занимают часы, а не дни.

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

Ускоряется обратная реакция на запросы потребителей. В этом уверены 95% респондентов, распределение их оценок степени ускорения представлено на диаграмме:

Так что же останавливает автоматизацию?

В результате опроса был составлен рейтинг стоп-факторов, которые в 2013 году тормозили прогресс в области сканирования и распознавания. Проценты респондентов, ссылающихся на конкретные трудности, представлены ниже:

Подытоживая

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

Тем не менее, только единицы компаний кидаются автоматизировать захват данных. И дело не в близорукости, а в иных приоритетах. За пределами ERP автоматизировать что-либо не верно, если еще в учетной системе не все расставлено по полочкам. Чтобы убедить компании расширять функционал своих систем за их пределами, вендорам нужно предоставлять услуги бизнес-консалтинга, не просто обещать положительный ROI, а выполнять обещания.

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

Если на конец 2013-ого в Штатах пройдено только 20% пути, в России трендом автоматизация захвата станет через 2-3 года.

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

Временные решения

При проектировании интерфейса (и программ вообще) достаточно часто сталкиваешься с ситуацией: «А давайте сделаем кнопку (окно, диалог и т.п.) пока такой (пусть и не очень подходящей), а потом при необходимости переделаем…». Так часто происходит, когда время поджимает, красивое решение сразу не находится и, вообще, «Мы же гибко разрабатываем - потом вернёмся и доделаем».

НО это «потом» наступает не всегда! Временные решения любят становиться постоянными и прорастать корнями в ИС так, что потом их не выдерешь. В таких случаях можно рекомендовать больше времени выделять на проектирование и поиск подходящих решений; или быть настоящим перфекционистом и улучшать временные решения на следующих итерациях (версиях).

Диалоги

Наверняка многие из вас сталкивались — и сталкиваются — с неадекватными или не понятными диалогами. Особенно программисты любят выдавать пользователям не понятные им сообщения об ошибках формата «Error 3456: нет возможности записать сведения в таблицу …». Что он хотел этим сказать пользователю? Он действительно считает, что пользователь его поймёт? Зачем вообще пользователю видеть такой текст ошибки?

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

Среди диалогов с запросом действия пользователя тоже встречаются интересные экземпляры. Например, у меня был случай когда, удалив объект из списка, я решил снова создать объект с таким же наименованием, и система мне выдала следующее:

Объект с таким наименованием существует.

[да]     [нет]

(Тут кроме неадекватного диалога ещё и добавился баг некорректной проверки уникальности наименования).

Господа разработчики, чаще ставьте себя на место пользователя и задавайте себе вопросы: А зачем я делаю такой диалог? А поймёт ли меня пользователь? А что я хочу от пользователя в этом диалоге получить?

Быстродействие глазами пользователя

Быстродействие глазами пользователя ≠ быстродействие глазами разработчика. Почему спросите вы? А вот почему.

Пользователь оценивает быстродействие с точки зрения получаемого им результата: за какое время (и клики) я могу получить то, что мне необходимо от программы. А разработчик с точки зрения процессов: за какое время система отрабатывает данный запрос в базу, за какое время отработает данная фича (кнопка, список, карточка и т.п.).

Т.е. все фичи в программе могут работать быстро, но для того чтобы пользователь получил результат, надо использовать, например, 20 таких фич, 30 раз кликнуть – и всё вместе это займёт очень приличное время.

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

Простота vs Сложность

Сделать простой интерфейс сложнее, чем сложный. Нагромоздить кучу кнопок, сделать непонятные переходы между страницами гораздо проще, чем уложиться в концепцию 3 клика, реализовать лаконичный и простой интерфейс.

Хороший пример реализации простоты интерфейса – продукция Apple - колесо для iPod (в iPod Shuffle даже дисплея нет, но им пользоваться очень просто); минимализм кнопок практически в любом продукте Apple; мультитач-интерфейсы под естественные движения пальцев и многое другое. Дизайну и интерфейсу Apple уделяло огромное внимание, очень тщательно его проектировало, Стив Джобс был ужасным перфекционистом. Рекомендую прочитать книгу Уолтера Айзексона «Стив Джобс».

Многие ИТ-шники – являются гиками (geek), и им не сложно, а даже интересно разобраться в сложной ИС. Им необходимо, чтобы было много настроек, чтобы можно было детально настроить систему под себя. Но большинству обывателей-пользователей это не надо, сложность их отпугивает.

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

Роль интерфейса при продаже ИС

Редко, но всё-таки встречал такие ситуации, когда заказчик говорит: «… у вас интерфейс лучше, поэтому выбрали вашу систему …». И это хорошо, что заказчики смотрят не только на стоимость системы и количество заявленного функционала в ней.

Но интерфейс ИС в процессе продажи и в процессе реального использования может играть совершенно разные роли. Обычно мы продаём лицам, принимающим решения, а систему потом используют совершенно другие люди. И у них могут быть совершенно разные цели и потребности!

После счастливого выбора ЛПР может наступить похмелье пользователя. Например, на демонстрации с небольшим количеством данных интерфейс смотрится привлекательно, а в реальной работе с реальными данными всё ужасно и перегружено, и различные «рюшечки» интерфейса уже не умиляют, а мешают работать.

Т.е. при проектировании интерфейса надо учитывать и его реальное использование, и его использование в процессе продажи ИС.

Минимально функциональный продукт

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

На практике данный подход реализуется по-разному. Первый вариант реализации: сделать минимум функций с отличным качеством и проработкой интерфейса. Второй вариант: сделать функций побольше, чтобы работали, а красоту в интерфейсе навести позже. Вы какой предпочитаете?

По-моему, первый предпочтительнее – лучше меньше, да лучше. :) Мне, как пользователю, приятнее пользоваться меньшим количеством качественной функциональности (и подождать дальнейшую реализацию), чем большим количеством непонятных и неудобных фич; возникают совершенно разные эмоции.

Жизнь, конечно, вносит в этот выбор много дополнительных факторов – что хочет получить заказчик, как вы ведёте конкурентную борьбу, что уже реализовано у конкурентов, что просят пользователи и т.п. То есть выбор, какой минимально функциональный продукт создавать и каким путём пойти к его созданию, будет зависеть от ваших целей и влияния окружения.

Во втором варианте есть ещё ловушка. Вы выпустили продукт с приличной функциональностью, но почему-то по части фич нет никаких толковых отзывов, пользователи их не используют. Можно сделать вывод, что они не нужны? Вероятно, но это не всегда так. Может, они нужны пользователям, но вы их сделали так, что ими невозможно пользоваться или об их существовании в вашем интерфейсе очень сложно догадаться. Получается, на разработку данных фич вы потратили кучу времени и денег, но все зря, и у вас нет никакого конкурентного преимущества. В этом случае, вам надо плотнее взаимодействовать с вашими пользователями - идите и посмотрите, как они работают; обратите внимание на ваш интерфейс; попробуйте поставить себя на место обычного пользователя.

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

А какие у вас есть заметки и подходы к проектированию интерфейсов?