В начале июня я модерировал конференцию «ИТ в промышленности». На круглом столе по обучению персонала возник интересный вопрос: можно ли создать промышленную программу с простым интерфейсом?
Если упростить интерфейс, то и обучать сотрудников не надо. Можно сравнить SAP, в интерфейсе которого нет ничего человеческого, и Убер. Почему-то никто же запускает курсы «как пользоваться убером»? А вот для SAP такие курсы необходимы.
На круглом столе пришли к мнению: нет, нельзя! У нас в управлении сложные системы со сложными процессами, которые нельзя упростить до Убера. Да и денег на это нет!
К сожалению, формат круглого стола не предполагал больших дискуссий, и обсудить детально тезис не получилось. Но, на мой взгляд, это ошибочное мнение. Давайте разберем почему.
Можно ли упростить интерфейсы?
Есть множество примеров, что упрощения интерфейсов. Компьютеры прошли от перфокарт до nocode. Куча кнопок в мобильном телефоне превратилась в добавить-убавить звук, стилус исчез. Раньше, чтобы управлять машиной, нужно было уметь менять свечи. Сейчас люди управляют машиной иногда не понимая, как залить воду в бачок омывателя, я уж не говорю про доливку масла.
То есть, примеров упрощения интерфейсов много. Почему же про промышленные системы получилось мнение, что упрощение невозможно?
Почему системы сложные?
Системы можно разделить на два класса:
системы для пользователя, S4U — systems for users. Это то, что используем мы с вами как конечные пользователи: айфон, убер, букинг.ком, айр-би-эн-би, легковые автомобили и так далее.
системы для бизнеса, S4B — systems for business. Это то, что компания поручает нам использовать: SAP, Oracle, 1C, самолеты и т.д.
Эти классы систем отличаются по направлениям развития:
1. Конечный пользователь не может добровольно отказаться от систем для бизнеса (S4B), в отличие от систем для пользователя (S4U). Если нам не нравится айфон — мы покупаем андроид, или наоборот. Мне не нравится приложение для заметок — я перехожу на другое, это полностью мое решение.
В системах для бизнеса не так. Сотрудники прикованы к системам для бизнеса трудовым договорами и должностными инструкциями. Мне не нравится интерфейс 1С — но я не могу отказаться от использования 1С.
2. Конечный пользователь не участвует в выборе систем для бизнеса (S4B). И даже если участвует, то фактор юзабилити не играет решающей роли при выборе системы. Сейлзы, которые не работают с системой, продают систему топ-менеджерам, которые тоже с системой не работают. Максимум смотрят отчеты в системе.
Системы для пользователей не могут не обращать внимание на удобство использования. Если бы интерфейс Убера был бы похож на интерфейс SAPа — то стартап бы умер, даже не начавшись. А если бы пользовательский опыт от айфона походил бы на использование компьютера с перфокартой — мы бы до сих пор сидели на телефонах с кнопками.
Системы для пользователей отбираются и эволюционируют, в том числе, по удобству использования. Оцениваются неправильные действия пользователей, как они влияют на опыт работы с приложением, повторные заказы и т.д., то есть интерфейс постоянно подстраивается под пользователя.
Системам для бизнеса, по большей части, наплевать на поведение пользователей — для них это вторая линия целей. Если пользователь что-то в системе не понимает, то это проблема конкретной компании и конкретного сотрудника: обучайте сотрудников тщательнее, вот вам инструкции (если повезет, то понятные и удобные), внедряйте наставничество и так далее.
Я как-то обсуждал личный кабинет сотрудника в одной из компаний. Я беспокоился, что люди не станут его использовать, так как интерфейс был достаточно сложным. На что получил прекрасный ответ: «Не надо беспокоиться! Мы им просто прикажем!!!» Подобный ответ я слышал и в других компаниях.
Работа с ошибками пользователей
Ошибка пользователя в системах для бизнеса всегда остается ответственностью самого пользователя. В 2005 году брокер японской компании вместо продажи 1 акции по цене 610 тыс. йен ввел приказ на продажу 610 тыс. акций по цене 1 йена. Ущерб составил 27 млрд. йен. При анализе этой ситуации никто не говорит про юзабилити софта, все говорят про ошибку брокера.
В моей практике был пример, когда оператор ввела цену товара 2500,00 вместо 25,00 руб.: заела запятая на клавиатуре или отвлекли. Эту цену согласовали коммерческий, финансовый и генеральный директора. Заметил только кладовщик — объем заказа не соотносился с суммой заказа.
После этого мы переработали портал ввода цен: ввели пробелы между разрядами, увеличили шрифт, добавили предупреждения и другие действия, чтобы снизить вероятность неправильного ввода цены. Неожиданно, как мне сказали операторы, работать с новой системой оказалось на порядок удобней!
Так что системы для бизнеса такие уродливые и неудобные не потому, что их нельзя сделать проще, а потому что компаниям и разработчикам наплевать на конечных пользователей. Главное: отчеты, производительность, масштабируемость и так далее.
Сколько стоит удобство
Как можно оценить удобство использования системы? Специалисты по промышленному дизайну скажут, что удобный интерфейс приносит огромное количество выгод: сокращение времени, снижение ошибок, меньше утомляемость и т.д.
Можно оценить юзабилити на простом примере. Предположим, что мы упростили одну операцию с 35 секунд до 5. Пользователь выполняет эту операцию 10 раз в день. То есть, экономия времени составит 5 минут в день: 30 секунд умножить на десять.
Экономия времени в год на одного пользователя составит: 5 минут на 240 рабочих дней, что дает нам 1200 минут или 20 часов или 2,5 рабочих дня. Если предположить, что в компании 1000 пользователей, то мы приходим к экономии в год 2500 рабочих дня, или 10 штатных единиц.
Если перевести это в деньги, то получается достаточно внушительная сумма. Если еще предположить, что для новой операции не нужно обучения и количество ошибок снижается в несколько раз, то эффективность простого изменения может быть просто гигантской.
Бизнес-логика
Но такая оценка наталкивается на суровую логику: как доказать эти расчеты?
Как мне сказал один из топов: Смотри, мы же не станем платить сотрудникам меньше от того, что они станут работать меньше? Значит, экономической выгоды нет. Так зачем же тратить деньги на проект, где нет экономической выгоды?
В чем-то эта логика правильная. Если у нас сотрудник работал ровно 8 часов, а сейчас он работает 7 часов 55 минут — мы все равно должны будем заплатить ему за 8 часов работы. Если следовать этой логике, то выгода от сокращения одной минуты равна нулю. Ну, компания же с этого ничего не выиграет!
Подобная оценка приводит к негативному эффекту: стоимость добавления еще одной минуты к рабочему времени тоже принимается равной нулю. Ну, сотрудник же не все 8 часов в день работает. Он болтает с коллегами, пьет чай, ходит в туалет! Значит, запас времени есть, и можно добавить еще минуты две-три, или даже 10 минут.
В моей практике был проект на 500 млн. руб, который не работал, так как не предусмотрели, кто будет тратить 5 (реально 5) минут в день. Система анализировала разные потоки данных, выдавала потенциально вредные ситуации, которые надо было разделить на безопасные и вредные. Как всегда бывает, это возложили на директора магазина, у которого и так была куча обязанностей — ему было не до этого. В итоге навороченная система генерировала поток данных, которые никто никак не использовал!
Возрастающая нагрузка
— Сколько у вас стоит капелька водки?
— Капелька? нисколько!
— Тогда накапайте мне стаканчик!
Системы для бизнеса постоянно расширяются. В компании может быть несколько проектов, каждый из которых добавляет одну-две или больше операций, никак это в затратах не показывая. Что в конечном итоге приводит к перегрузке сотрудников.
Сотрудники, конечно, будут жаловаться на возрастающий объем работы. Но тут вступает другая логика: раньше же все успевали! Тут всего лишь пару простых операций в системе добавили. Вы просто не хотите или не умеете работать. А если какую-нибудь операцию сотрудники выполняют за 10 минут, то все будут говорить про неразвитое поколение, кривую обучения, некачественную подготовку сотрудников и т.д. А система? Система воспринимается как данность: в других компаниях же работают!
Рост нагрузки на сотрудника в конечном итоге приводит к повышению текучести персонала. Текучесть персонала измеряется просто, но доказать причинно-следственную связь между неудобными программами и текучестью фактически невозможно! На текучесть влияет множество факторов, и выделить влияние одной операции на уход сотрудника — нужны масштабные исследования, на которые нужны время и деньги.
В сухом остатке получается, что хотя эффективность и выгода от повышения юзабилити значительна, но доказать ее мы не можем. В таком случае более значимыми становятся проекты, в которых проще рассчитать показатели, нежели проекты, которые могут кардинально поменять работу в компании. В этом случае бизнес-поговорка: «если ты не можешь что-то измерить, то ты не можешь этим управлять» превращается в «ты управляешь тем, что проще всего измерить».
Заключение
Повышение юзабилити систем приводит к значительным выгодам: экономится время сотрудников, уменьшается время на обучение, снижается количество ошибок и так далее. Чем больше компания — тем значительнее будет эффект.
Текущие практики оценки проектов не позволяют доказать выгоды от повышения юзабилити:
1. Если мы сократим время одной операции — то мы не уволим никого из сотрудников.
2. Если сотрудник не успевает что-то сделать — это его ответственность.
3. Влияние прочих факторов доказать сложно, поэтому их в расчет не принимают.
Чтобы избежать подобной логики, нужно говорить не про количество штатных единиц, а про пул рабочего времени в распоряжении компании. Мы сократили время работы с системой на 2500 человекодней в год? Значит, мы увеличили возможности компании на это время. То, как компания использует этот пул времени — это вопрос эффективности операционных процедур компании, но не вопрос эффективности повышения юзабилити.
На мой взгляд, все должны взять как цель доведение интерфейса S4B до уровня S4U. Да, заказ такси всегда будет проще, чем управление атомной электростанцией. Разработать для всех систем софт, подобный уберу, скорее всего невозможно. Но цель не в том, чтобы довести интерфейсы всех систем до уровня одной кнопки, а в том, чтобы постоянно повышать удобство использования и упрощать системы. Даже если повысить юзабилити систем на 10-20 %, то будет просто круто.
Сама посылка, что системы для бизнеса нельзя привести к уровню убера — вредна, так как не двигает системы в правильном направлении.
Автор: Алексей Коряков
