Для большинства из нас понятие «обучение» осталось в прошлом вместе с окончанием какого-либо учебного заведения. Вероятно, по этой причине на доброй половине проектов по внедрению программных продуктов 1С, представители или отказываются от этого этапа в явном виде, или же предпочитают точечное обучение сотрудников «на местах», не предавая должного значения этому моменту.

Однако, в условиях нынешнего уровня автоматизация, данный подход в корне неверен. Часто именно это становится причиной так называемого «человеческого» фактора, играющего роковую роль в «провальных» проектах.

Что тут скажешь… Учиться никогда не поздно и никому не рано.

В наши дни, когда программные продукты находятся на уровне целостных интеграционных систем, представляющих собой набор взаимосвязанных между собою блоков, относиться к своей работе локально – не совсем верно.

Конечно, все действия сотрудника, а также доступная ему информация должны целиком и полностью покрываться его зоной прав доступа и ответственности. Однако, ответственность сотрудника должна быть ещё и в понимании того, что от его действий может зависеть информация в смежных блоках.

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

Когда встаёт речь об автоматизации, как правило, предприятие в силу различных причин ощущает необходимость перехода на другой программный продукт. Планируемый программный продукт может или быть той же линейки, что и эксплуатируемый (например, переход в рамках одной линейки, но на ступень поколения выше). Или же в корне отличаться (например, когда переход осуществляется с программного продукта одного производителя на программный продукт другого производителя). В обоих случаях в рамках предварительного обследования возникает диалог между представителем компании Исполнителя и представителем компании Заказчика.

Представитель компании Исполнителя прекрасно знает программный продукт, но может и не подозревать о некоторых нюансах учёта компании Заказчика. Представитель компании Заказчика знает все нюансы учёта, но понятия не имеет о функционале будущего программного продукта. Именно в этом моменте возникает та самая несостыковка, которая в последствии может привести к серьёзным корректировкам первоначальных требований. Как пример можно привести какой-нибудь «незначительный» по мнению сотрудников предприятия Заказчика реквизит, который, как выясняется несколько позже, должен присутствовать чуть ли не как основной разрез аналитики…

Как показывает практика, полностью сгладить этот момент не получается, даже при наличии сверх опытных сотрудников с обеих сторон.

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

Соответственно, можно подытожить, что комплексное обучение на старте проекта по внедрению имеет следующие преимущества:

- формирование более полных и точных требований;

- более корректный ввод первичной документации на этапе тестовой эксплуатации пользователями;

- уменьшение срока тестовой эксплуатации за счёт уменьшения количества выверок и исправления ошибок, уменьшение длительности проекта в целом.