Как перекладывание ответственности мешает внедрить управленческий учет в 1С

 

О перекладывании ответственности со стороны пользователей заказчика. И о том, как это мешает внедрить проект по управленческому учету в 1С.

Итак, мы с Вами уже поднимали тему перекладывания ответственности в прошлой статье “Как руководитель может помешать внедрить управленческий учет в 1С”. Сейчас немного продолжим и расширим эту тему.

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

Разумеется, как правило, дальше пишется техническое задание (далее — ТЗ), которое мы потом пытаемся согласовать с этим самым пользователем. И вот тут может следовать этап “затягивания”. На данном этапе, такой пользователь, который хочет переложить на нас ответственность, обычно, просто не отвечает на электронные письма. Встретиться он тоже в ближайшее время с нами не может, очень занят. По телефону говорит, что пока нет времени почитать ТЗ и он же нам все рассказал, что он хочет получить. В итоге, если ждать, пока мы сможем с ним встретиться и согласовать ТЗ — работа будет делаться очень долго. И тогда, пользователь вполне может на нас пожаловаться руководителю, в связи с тем, что мы затягиваем работу. Тогда мы задаем пользователю вопрос по телефону: отдавать ТЗ в работу без согласования? Пользователь отвечает: да, я же Вам все рассказал! Все, вот тут ловушка и захлопнулась, сейчас мы рассмотрим, почему.

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

• Я недоволен чем-то, значит, Вы плохо меня поняли, и Вы неправильно сделали, соответственно, Вы виноваты.
• Сделать можно было по-разному, мы хотели обсудить с Вами вариант, который нам показался оптимальным, но Вы были заняты. И мы сделали все согласно ТЗ, который отправляли Вам до того, как отдали его в работу.
• Я не видел Вашего ТЗ, у меня не было времени. Но я Вам все правильно рассказал еще тогда, когда мы с Вами обсуждали задание.

Как видите, пользователь ссылается на те данные, которые он давал устно и их уже нельзя перепроверить и, так сказать, фальсифицировать. А те данные, которые есть в письменном виде — пользователь подтверждать не хочет.

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

И, тогда, по административному приказу, пользователь, конечно, должен выделять время и согласовывать с нами не только пожелания, но и реализацию задачи. Либо, если руководитель решит, что затягивание — не критично, то мы будем ждать пользователя. И когда он освободится — согласовывать с ним ТЗ, а затем уже принимать это задание в работу…

Более подробно о том, какая, с нашей точки зрения, роль руководителя предприятия заказчика во внедрении проекта 1С в статье “Как руководитель в качестве арбитра может помочь внедрить управленческий учет в 1С”.

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