Руководитель в качестве арбитра залог быстро и успешно внедрить управленческий учет в 1С

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

Давайте, вначале, вспомним этот бородатый анекдот:

• Рабинович, вы у нас вчера были в гостях?
• Был!
• Так вот после вашего ухода пропали серебряные ложки!
• Но я их не брал, я порядочный человек!
• Но ложки все-таки пропали! Так что больше не приходите к нам в гости!

Позже:

• Рабинович, ложки нашлись !
• Так что, можно приходить в гости?
• Э нет, ложечки-то нашлись, но осадок остался !

Так вот, работа с клиентом, иногда, напоминает этот анекдот. Пользователь заявляет о найденной ошибке в программе. Вероятно, при этом, ставит в известность руководителя. Так вот, лично для меня — человека, который в теме 1С уже 14 лет — тот факт, что пользователем найдена ошибка означает один из следующих вариантов:

1. Действительно, наша ошибка в доработке.
2. Пользователь (или кто-то другой, например, его коллега) ввел некорректные данные, а результат доработки, учитывая эти данные, получился как раз правильным. А бывает и так, что данные были корректные, программа все правильно посчитала, а пользователь, наоборот, все это время до доработки неправильно считал.
3. Пользователь забыл, как нужно работать с данной доработкой.
4. Доработка не работает при новых условиях, которые не обсуждались при постановке задачи. Эти нюансы теперь отрабатываются как новая задача. И это не потому, что прошел некий гарантийный срок и тому подобное. Если бы эти нюансы сразу были известны, то доработка изначально стоила бы дороже.
5. Доработку сделали не так, как пользователь ожидал. Он ставил задачу устно, а когда она была спроектирована — отказался согласовывать, ссылаясь на занятость и на то, что он уже все объяснил, как должно быть. Более подробно об этом виде проблемы, читайте в статье: “Как перекладывание ответственности мешает внедрить управленческий учет в 1С”.

И, нужно сказать, что на 1-й пункт приходятся далеко не все жалобы. Важно то, что, если выяснилось, что ошибка была, действительно, не наша — пользователь не видит смысла информировать руководителя, что мы здесь все-таки не виноваты. Признаваться, что это он в чем-то ошибся — никому не хочется. И, руководитель, как правило, впитывает только негативные отзывы своих сотрудников о нас. Ведь, согласитесь, редко какой пользователь скажет ему, мол, как прекрасно ребята отработали, душа радуется! Да, и такое бывает, просто намного реже. Каждый раз, когда нас в чем-то обвиняют, мы проводим свое внутреннее расследование — таковы наши стандарты качества. Если обвинение было с копией письма руководителю, мы отвечаем тоже, с копией руководителю. Опять-же, если руководителя не информировали об ошибке, то и результат “расследования” высылается только пользователю, который сообщил о ней. Незачем лишний раз дергать руководителя.

Оставлять все как есть — это играть с огнем, так как ты соглашаешься с обвинениями. Я готов соглашаться, разумеется, когда это так и есть. Но очень часто это не так. И человеческий фактор здесь играет, как никогда, большую роль.

Думаю, Вы слышали такое мнение, что после обновления программы “все слетает”? Так вот, недавно мы делали одной компании обновление. И они, после этого, заявили, что слетели некоторые доработки. Мы подняли базу до обновления, проверили, и, оказалось, что эти доработки до обновления работают точно также, как и после. Все доказательства были предоставлены, и, так сказать, обвинения были сняты. Заказчик увидел, что они были беспочвенны.

Или, как пример, мой партнер Олег Горбенко недавно рассказал мне один случай, который с ним произошел. Закрыли у клиента в базе январь 2015 года. На момент закрытия — все было хорошо. Сейчас видно, что какие-то цифры порвали учет. Олег говорит заказчику, мол, Вы после закрытия месяца что-то, видимо, в январе перепровели. Подняли базу из архива. Видно, что в архивной базе один из документов не проведен, а в текущей версии базы — проведен. От заказчика посыпались тут же обвинения, что это, именно, Олег зачем-то провел данный документ. Тоесть, заказчик сразу начал обвинять нас, по принципу, что, кто лучше разбирается в 1С, тот и виноват. Прямым текстом это не говорил, но месседж был именно такой. В итоге, Олег покопался и обнаружил, что все-таки сам заказчик перепровел этот документ и, плюс к этому, нашли, что в одном из документов заказчик уже, опять-таки, после закрытия месяца поменял % скидки. Знал, что такого нельзя делать, молча это сделал и не перепровел документ “Закрытие месяца”, согласно инструкции. И таких случаев на практике очень много. Причем, это редко происходит специально. Скорее, пользователи о том, что они что-то поменяли задним числом, по прошествии времени, просто забывают. Забывают и обвиняют, потом,  нас.

Да, были и случаи, когда мой человек откровенно “тупил” и я снимал часы за эту работу и возвращал их обратно на счет заказчика. Опять-же, в случае наших обоснованных ошибок были и варианты, когда я полностью возвращал деньги, хотя такой предварительной договоренности с заказчиком не было. Если обвинения справедливы, то и я справедливо на них реагирую. Тем не менее, куда чаще обвинения сыпятся необоснованные. Что поделать, пользователи годами привыкают обвинять во всем программистов. А те годами соглашаются где виноваты, и где не виноваты.

Понятное дело, что, когда руководителю жалуются его сотрудники, с которыми он проработал уже год-два, а то и 5-10 лет, то он более склонен, изначально, им поверить. Потому, мы стараемся сразу вооружить руководителя заказчика, так сказать, “критическим мышлением”. Рассказать, как пользователи себя ведут в других компаниях, предупредить о том, как на это реагировать. Опять-же, здесь редко, со стороны пользователей, присутствует “злой умысел”. Просто с каждым заявлением об ошибке, нужно детально разбираться и давать “заключение”.

Вот и хочется сразу заметить, что нужно слушать обе стороны в конфликте, а не только удовлетворяться мнением одной из сторон. И знать о том, что ошибки неизбежны, и, что потери позволяет снизить своевременное тестирование пользователями заказчика доработок. И о том, что не стоит с первого раза ожидать всего идеального. Обо всем это статья “Как ожидание идеального и несвоевременное тестирование мешает внедрить управленческий учет в 1С”. Также, считаем своим долгом предупредить и о том, как некоторые пользователи, с удовольствием, любят перекладывать ответственность за все на нас. Об этом в статье “Как перекладывание ответственности мешает внедрить управленческий учет в 1С”. Более того, стараемся предупредить ситуации, когда сам руководитель может привнести большую долю человеческого фактора, если собирается сам вести в программе какой-то из участков. Об этом статья: “Как руководитель может помешать внедрить управленческий учет в 1С”.

Опять-же, если у людей с нашей стороны, и со стороны заказчика обычный человеческий конфликт, можно заменить специалиста с нашей стороны. Банально, бывает, что люди “несовместимы” и просто не могут выносить друг-друга. Возможно, с другим человеком работа пойдет намного лучше. Опыт есть, и такие действия реально помогают при работе с некоторыми заказчиками. А есть заказчики, которым меняй-не меняй, все равно остаются недовольны.

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

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

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

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер».