Хочу рассказать про одно простое правило, которое может здорово облегчить сотрудникам службы поддержки пользователей их работу. Сложность современных бизнес-приложений вообще, и например ERP-систем в частности, такова, что держать все настройки, и все возможные ситуации в голове одному человеку сложно, да и не нужно. Если вы, что то забыли, то всегда можно обратиться к документации, которая поставляется вместе с системой, а также к той документации, которую вы создали сами. Но, вот ведь в чем беда - зачастую для того чтобы решить пустяковую задачку сотрудникам поддержки приходиться "перелопатить" кучу документации, а также потратить немало времени создавая примеры на тестовых приложениях.
Облегчить повседневную работу можно, если использовать правило, назову его правилом умной ошибки, которое состоит в том, что любое сообщение об ошибке или информационное сообщение, которое ваша система выдает на экран, должно содержать идентификатор этой ошибки, по которому можно быстро и легко найти дополнительную подробную информацию о причинах её возникновения.
Приведу простой пример:
Допустим от пользователя поступила заявка, что мол "Я не могу выписать счет, т.к. система ругается "Не указан ответственный менеджер по клиенту ХХХ". Если сотрудник поддержки уже встречался с такой ошибкой, то конечно, он быстро разберется, где в настройках клиента указывается ответственный менеджер, а вот если он встретился с такой ошибкой в первый раз, то вынужден будет вначале самостоятельно разобраться, кто такой ответственный менеджер, за что он ответственный и почему, если он не указан нельзя выписать счет клиенту, где его нужно указать, и кто это должен сделать.
И вот тут на помощь приходит умное сообщение об ошибке, которое могло бы выглядеть, например так: "Не указан ответственный менеджер по клиенту ХХХ (см. NKS-11348)", где NKS-11348 - это ссылка на подробное описание этой ошибки. Описание может быть в виде статьи в базе знаний, или просто ссылкой на какой-то раздел руководства пользователя. Особенно актуальной такая идентификация каждой ошибки становиться, если вы вносите модификации в стандартный функционал вашей ERP-системы. В этом случае даже опытному консультанту без подобной "подсказки" будет трудно разобраться в нестандартном "поведении системы".
Несмотря на всю очевидность и простоту этого правила, к сожалению, разработчики приложений зачастую им пренебрегают. А ведь, если всегда придерживаться этого правила в разработке, то последующая работа с вашим приложением, выполнение настроек и разрешение трудных ситуаций становятся гораздо менее трудоемкими занятиями.
Облегчить повседневную работу можно, если использовать правило, назову его правилом умной ошибки, которое состоит в том, что любое сообщение об ошибке или информационное сообщение, которое ваша система выдает на экран, должно содержать идентификатор этой ошибки, по которому можно быстро и легко найти дополнительную подробную информацию о причинах её возникновения.
Приведу простой пример:
Допустим от пользователя поступила заявка, что мол "Я не могу выписать счет, т.к. система ругается "Не указан ответственный менеджер по клиенту ХХХ". Если сотрудник поддержки уже встречался с такой ошибкой, то конечно, он быстро разберется, где в настройках клиента указывается ответственный менеджер, а вот если он встретился с такой ошибкой в первый раз, то вынужден будет вначале самостоятельно разобраться, кто такой ответственный менеджер, за что он ответственный и почему, если он не указан нельзя выписать счет клиенту, где его нужно указать, и кто это должен сделать.
И вот тут на помощь приходит умное сообщение об ошибке, которое могло бы выглядеть, например так: "Не указан ответственный менеджер по клиенту ХХХ (см. NKS-11348)", где NKS-11348 - это ссылка на подробное описание этой ошибки. Описание может быть в виде статьи в базе знаний, или просто ссылкой на какой-то раздел руководства пользователя. Особенно актуальной такая идентификация каждой ошибки становиться, если вы вносите модификации в стандартный функционал вашей ERP-системы. В этом случае даже опытному консультанту без подобной "подсказки" будет трудно разобраться в нестандартном "поведении системы".
Несмотря на всю очевидность и простоту этого правила, к сожалению, разработчики приложений зачастую им пренебрегают. А ведь, если всегда придерживаться этого правила в разработке, то последующая работа с вашим приложением, выполнение настроек и разрешение трудных ситуаций становятся гораздо менее трудоемкими занятиями.
