Три принципа обслуживания клиентов
Примерно 10 лет назад сформулировал для себя и своих подчиненных важные принципы оказания услуг в сфере информационных технологий. Чтобы со временем формулировки не забылись и не исказились, записал их в файл. Именно это и послужило началом моей десятилетней писанины "в стол" в надежде когда-нибудь это опубликовать. И вот сейчас пришло время ознакомить читателей с этими принципами. Почему я считаю их важными? Потому что большинство, к сожалению, продолжает делать наоборот...
Принцип №1: Внедряйте простые решения, учитывайте, что предшественники могли внедрить сложные
Как-то в небольшом офисе поднял wi-fi сеть, надо сказать, что тогда это было в диковинку. Проблема была с серверной комнатой, она была далековато от точки доступа, в помещении бывшей кассы за железной дверью, в общем сигнал был не всегда стабильным. Чтобы это исправить, поднял еще одну точку в серверной, антенну вывел наружу и соединил два устройства в режиме моста. Связь заработала прекрасно, я был очень доволен собой. Но однажды в офисе пропал интернет. От провайдера решать проблему пришел слишком самоуверенный молодой человек, который первым делом сбросил настройки основной точки доступа и перенастроил ее заново. Связь не появилась. Мастер на все руки признал, что проблема на их стороне. А когда сотрудники сообщили, что теперь не могут подключиться еще и к серверу, а только что могли, пожал плечами и ушел. Я тогда находился на отдыхе в другой стране. Ситуацию спас мой друг (Костя, привет). А надо было не выпендриваться и вместо моста просто прокинуть до серверной обычный провод и все.
Что же произошло... Представитель провайдера не ожидал сложного решения и нечаянно все сломал. Когда вы делаете что-нибудь нестандартное, пусть даже оно какое-нибудь передовое, будьте готовы к тому, что вас не поймут, или ваш преемник, или какой-нибудь ремонтник. Чтобы этого избежать, старайтесь по возможности делать просто и предсказуемо. И наоборот, если вы входите в новый проект или приехали на разовый вызов, будьте аккуратны, всегда ожидайте подвоха в виде сложного решения, перед любыми изменениями расспросите всех, кто может знать хоть что-то, как оно работало. В любом случае даже простые стандартные решения нуждаются в документировании.
Принцип №2: Добивайтесь закрепления ответственных сотрудников за каждым автоматизированным бизнес-процессом
Как-то у моей компании появились филиалы в других городах по паре сотрудников просто для продаж, для выписки расходных документов. Я настроил автоматическую систему выгрузки данных из филиальных баз в центральный офис по ночам. Сотрудники филиалов об этом не подозревали, это был, в том числе, элемент контроля. Информация об актуальности данных из каждого города даже выводилась на внутренний сайт компании. Я был очень доволен собой. Но вдруг стал замечать, что выгрузки приходят очень нерегулярно или вообще редко по самым разным причинам, вплоть до электрических. То есть, автоматическая система не работала как от нее требовалось.
Потом на другой работе сделал по другому. За выгрузку данных были назначены ответственные: товароведы работающие посменно. Можно было просто нажать одну кнопку и все сделает автоматика, либо если какие-нибудь настройки сбились, люди были обучены сделать то же самое вручную, фактически нажать несколько кнопок, либо если пропадал интернет, выгружали файл себе на флешку и отправляли по почте из дома. Такой подход очевидно работал устойчиво.
Дело в том, что любая автоматизация сама по себе ненадежна и бессмысленна. Необходимо, чтобы за каждым автоматизированным бизнес-процессом был закреплен ответственный сотрудник, который в случае сбоя или нестандартной ситуации должен суметь выполнить необходимые действия по другому, с помощью какого-нибудь запасного варианта, ну или хотя бы смог позвонить тому, кто разберется. То есть, автоматизация - это всего лишь помощь ответственному лицу при выполнении регулярных действий.
Принцип №3: Делайте больше, чем вас просят, даже если за переработку не заплатят
Как-то принимал дела у внешнего программиста, который представлял официальную фирму франчайзи 1С. Спросил у него, почему не настроено архивирование. Его ответ был впечатляющим: "Нас об этом не просили". Так заказчик может и не знать, что нужно, а что нет. Как минимум важные моменты надо было предложить и заработать на этом дополнительные деньги или даже сделать бесплатно, бонусом, потому что рано или поздно это было бы оценено.
То же самое с техническим заданием. Ну не умеют заказчики писать все что нужно, что-то обязательно упускают. Необходимо во-первых, им помочь, а во-вторых, быть готовыми во время внедрения к уточняющим несложным доработкам. И еще момент, если рядовые сотрудники заказчика, которые как раз и будут пользователями внедряемой системы, просят улучшение в интерфейсе, которого не было и не могло быть в ТЗ, нужно обязательно это сделать без всяких согласований, хотя бы бесплатно. Во-первых, пользователи будут довольны и это дойдет до руководства, во-вторых, такое же улучшение вы сможете внедрить на другом проекте уже за деньги.
Вывод
Соблюдение представленных принципов позволяет переводить проекты в статус долгосрочного взаимовыгодного сотрудничества.