Ни в ЗУП ногой!? А мне нравится! Часть 3. Как меня туда занесло?

Ссылки на остальные части статьи:

1. Главные сложности решения, что отталкивает?

2. Плюсы решения, где они прячутся?

4. Главное - правильный перенос данных!

Сразу стоит отметить, что данная статья - это не мемуары 80-л етнего... Как и предыдущие статьи, она написана о моём опыте, но содержит массу полезных рекомендаций! Цель данной статьи - рассказать, как войти в "профессию" и развиваться в ней. 

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

1. Курсы по направлению ЗУП

Как вообще попадают в эту предметную область:

• Вы новый сотрудник (возможно, студент), на Вас накидывают всю работу, которой никто не хочет заниматься. Часто задачи по ЗУП - это именно то, чем никто не хочет заниматься! Можно сравнить с обучением плавать - кинули, как собаку в озеро, хочешь выжить - плыви! Те, кто не выплыл, - увольняются. Будьте готовы в такой ситуации изучить огромный пласт специфической информации.
• Некоторые кадровики или бухгалтера по расчету зарплаты видят размер заработка в этой сфере, решают повысить свой доход путём смены профессии на консультант по ЗУП. В первой статье описывал набор необходимых знаний. У расчетчиков и кадровиков есть практически все знания для работы консультантом ЗУП.
• Все, кто попал в эту предметную область, испытывают жуткий дефицит знаний! Для этого джуниоров отправляют на курсы. Проблема в том, что с курсов далеко не все приносят знания. Чаще всего приносят сертификат об их прохождении. Понятное дело, что  работе это не поможет! Ниже опишу, как пройти курсы с пользой для дела.
• Бывает, и опытные коллеги попадают в эту предметную область. Обычно вход в профессию начинается с задач переноса данных, простых отчетов и т.д. Либо со слов: ты ж разработчик! Какая тебе разница, где программировать?)))

Теми же путями и мне повезло оказаться в ЗУПе. 14 лет назад проходил курсы по платформе 8.1 в Краснодаре. Курс читал всем известный Павел Белоусов. На следующей неделе был курс по конфигурированию подсистем расчета зарплаты. Вот и решил послушать, раз уж оказался там) 

Потом разместил информацию о прохождении курсов по ЗУП в резюме, и началось... Т.к. я был несколько раз "новеньким", на меня спихнули всё, что связано с ЗУПом))) Если вдруг кто-то прошёл курсы по ЗУП и не хочет "попасть в профессию" - лучше не писать об этом в резюме. Тогда Вас ждёт успешная карьера по УТ или Бухгалтерии. 

Как пройти курсы, чтобы было полезно:

• Как ни странно, к курсам надо готовиться! Если есть заблуждение, что на курсах обязательно научат любого, - от него стоит избавиться заблаговременно! 
• Необходимо изучить программу курса. Внимательно прочитать каждый пункт. Отметьте для себя, какие знания на входе Вы имеете, т.е. понятные темы.
• По каждой теме рекомендую почитать статьи. Это 15 лет назад в интернете только рефераты скачивали, потому и ходили на курсы. Сейчас информации на любую тему валом. 
• При чтении статей запишите себе вопросы, которые непонятны. Да, совсем новичкам здесь будет туго! Ибо непонятно всё, включая то, зачем решил работать с ЗУПом?! Но наш мозг устроен удивительным образом... Если в него накидать непонятной информации и пойти на курсы, чаще будете слышать знакомые слова и информация будет структурироваться благодаря пояснениям преподавателя. 
• На все непонятные вопросы Вы обязательно должны найти ответ! Его можно получить как в рамках курса, так и в рамках личного общения с преподавателем и другими слушателями.
• По окончании курса посмотрите на список тем ещё раз. Отметьте темы, которые до сих пор непонятны. 
• По этим темам проходим ещё раз, изучаем дидактические материалы с курсов и статьи в интернете. Уверен, получится разобраться. 

ВАЖНО: При таком подходе курсы принесут работнику максимум знаний, а работодателю - максимальную пользу! Берите на вооружение!

Мой личный опыт на момент начала курсов по Платформе состоял из 7 неудачных попыток сдачи специалиста по платформе. Поэтому я четко знал, что мне нужно выяснить на курсе. Благодаря этому, сразу по окончании курса успешно сдал этот экзамен с 8-й попытки))).

2. Сертификат "Специалист" по направлению ЗУП

Здесь надо отметить, что сначала нужно пройти квест-угадайку под названием "1С:Профессионал". Экзамен проводится в виде теста. Вопросы странные, большинство к реальной жизни не имеют никакого отношения, но надо угадать 12 из 14. Много лет назад получилось схитрить - купил ответы на этот экзамен в Эксель и "списал" благодаря знакомым))) Сейчас такой номер не прокатит - придётся готовиться по специальной книге. 

Раз прошел курсы по конфигурированию - значит, надо получить сертификат "1С:Специалист"! Все думают, что это какое-то полезное действие и сертификат точно говорит о том, что перед Вами спец! На деле это далеко от написанного. 

Для консультантов и аналитиков есть экзамен "1С:Специалист-консультант". Суть его такая же, только задача не предполагает программирования. Всё делается в пользовательском режиме.

Много раз участвовал в собеседованиях, приходили люди с сертификатом, но без знаний и опыта. К сожалению, опыт и глубокие знания мы получаем через 3-5 лет после получения сертификата. Мой сертификат спрашивали только франчайзи, пока такие спецы были редкостью. За последние лет 8 ни разу не спрашивали) 

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

Всем нам приходится участвовать в собеседованиях. Некоторым выпадает возможность быть собеседующим. Текст ниже должен Вам помочь отделить грамотного кандидата от новичка. Те, кто на собеседовании кандидат - сможете понять важные моменты, которые необходимо продемонстрировать на собеседовании.

Как же определить, перед Вами специалист или начинающий программист/аналитик? Если раскрывать этот вопрос без привязки к ЗУП, то стоит писать отдельную статью. Да и написано их уже много... Опишу свой способ проведения собеседования по ЗУП:

• Хорошего ЗУПера всегда выдаёт хорошее и глубокое знание предметной области! Причём не важно - разработчик это или аналитик/консультант. Любой Ваш вопрос должен предполагать, что в ответе расскажут о частичке предметной области. 
• Начните Вашу беседу не со стандартных вопросов "Почему выбрали нас"... Задайте такой вопрос: "Расскажите о выполненной Вами большой задаче, которой Вы гордитесь!?" Человеку с опытом всегда есть о чём рассказать. Много раз наблюдал, как кандидат взахлёб с горящими глазами рассказывает о своих достижениях и какой ценой они дались. В процессе диалога можно задавать вопросы по предметной области, попросить аргументировать принятое решение. Если кандидат этого не может, поверьте - ничего кроме простых отчетов и обработок он делать не сможет! Если это аналитик/консультант - значит, перед Вами первая линия консультаций. 
• Люди с большим опытом хорошо знают существующие схемы оплат труда, работали с вахтой, сделкой, налогами, территориальными условиями МКС/РКС и четко понимают все сопутствующие бизнес-процессы.
• Заготовленные тесты и задания не покажут уровень, задавайте чёткие вопросы по архитектуре решения и предметной области. Если это разработчик - он обязан знать менеджер расчета зарплаты и представления! Если это аналитик - налоги и взносы со всеми особенностями исчисления должны знать на зубок.
• В первых статьях обращал уже внимание на важность качества работы в ЗУП. Стройте свои вопросы так, чтобы становилось понятно, что кандидат хорошо прорабатывает задачу, изучает сценарии, тестирует на больших массивах данных и т.д. Здесь важен именно результат, а не процесс.

Такой вот незамысловатый способ позволяет выяснить абсолютно всё о кандидате без "стандартных" вопросов, которые меня лично вводят в ступор! Когда слышу вопрос: "Почему Вы хотите работать в нашей компании?", хочется в ответ спросить: "Почему Вы так уверены, что я хочу у Вас работать?". Просто пришёл познакомиться! Появится такое желание или нет - зависит от собеседования, от честности и открытости всех участников. 

ВАЖНО: Отдельно хочу подчеркнуть для тех, кто приходит на собеседование - никогда не пытайтесь врать! Честность - залог успеха! Всё равно станет понятно, кто Вы такой. Расскажите сами о своих недостатках и проблемах, какие пути их устранения Вы видите!? То же самое относится к работодателям!

Несмотря на мой неудачный опыт работы в компании 1С, за 18 лет опыта считаю их самой честной компанией! Мне сразу рассказали обо всех недостатках. И только потом начали говорить о плюсах! Но это не реклама, конечно!

3. Перенос данных из старого ЗУП (ЗиК) в новый. Чем поможет такая задача?

Всегда встает вопрос: какие задачи можно дать начинающим программистам? Лично от себя рекомендую давать отчеты и печатные формы! Всё просто - отчет построены на запросах, запросы отражают архитектуру решения. Когда пробуешь строить отчет, обязательно полезешь вводить новые данные. Тем самым, разберёшься ещё и с документами/справочниками/сценариями работы. На таких задачах многие неплохо растут профессионально!

Мой опыт строился иначе. Меня посадили переносить данные из ЗиК 7.7, а потом ещё из Паруса в ЗУП 2.5. Это был способ изучить восьмерку. На момент начала работы зарплатой не занимался совсем. Расскажу, какие плюсы были для меня от такого решения. Конечно, сейчас вряд ли кто-то рискнёт начинающему дать такую задачу. Однако такой задачей можно нагрузить сотрудника с опытом пару лет. Пусть развивается! Итак плюсы:

• Разобраться, какие бизнес-процессы будут работать с первых дней в новой версии ЗУП.
• Какие данные нужны для запуска этих бизнес-процессов.
• Где хранятся необходимые данные, а значит, подразобраться в архитектуре решения.
• Поиск данных в предыдущей версии решения расширит кругозор.
• Если догадаться проверить данные в источнике, можно разобраться в вопросе "как должны выглядеть правильные данные".
• Получен опыт разработки больших обработок. Написано много кода (о качестве пока не говорим).

Вполне себе неплохая задача для старта. Но здесь без опытного и терпеливого наставника не обойтись!

Приведу несколько примеров вовлечения новичков в серьёзные задачи:

• Коллега никогда раньше не работала с управляемыми формами. Но был хороший опыт работы с ЗУП 2.5. Ей было поручено автоматизировать печать примерно 60 печатных форм. Но сделать нужно было не 60 обработок, а одну универсальную. С поставленной задачей успешно справилась. Попутно разобралась с клиент-серверным вариантом работы и управляемыми формами.
• Начинающий консультант обмолвилась, что раньше работала расчетчиком зарплаты. Но с ЗУП 3 не знакома. Ей была поручена сложная задача по НДФЛ. Т.к. предметная область была хорошо знакома, с задачей справилась. Попутно разобралась со всеми особенностями начисления зарплаты в ЗУП 3. 
• На одном из проектов работал консультант по договору ГПХ. Он заметил в базе одной из организаций холдинга ошибки в переносе данных. Были проанализированы остальные базы холдинга, выяснилось, что ошибки массовые. Позднее несколько лет успешно работали на проекте в Роснефти. Ему поручались сложные задачи с большим количеством неизвестных. Также успешно справлялся.
• На одном из проектов нужно было выполнить большое обновление сильно доработанной базы. Коллега ранее не занималась такой работой. Приходилось много делать в качестве показательного примера. Задача также была успешно выполнена.

Старайтесь при постановке задач "угадывать" исполнителя. Учитывайте компетенции и желание развиваться и делать качественно. Это позволит развивать компетенции начинающих коллег.

4. Востребованность знаний, дефицит специалистов на рынке.

Всем известно, что запуск проекта по переходу на ЗУП имеет одну сложность - непонятно, где набрать людей, которые его хорошо знают! Все 14 лет работы в этой сфере также сталкивался с дефицитом кадров и глубоких знаний. В первой статье писал о том, насколько важно выполнять работу качественно. Чуть выше описал, как подобрать хорошего специалиста в области ЗУП.

Рассмотрим в этом пункте такой вопрос: "Как остаться востребованным?" 

Разделим вопрос на 2 составляющие, и посмотрим, благодаря чему можно этого достичь:

• Высокая ответственность за результат
• Высокие требования к качеству

Высокая ответственность за результат. Способы повышения ответственности:

• Первым делом нужно понять, как должен выглядеть правильный результат. Пока нет этого понимания, браться за выполнение задачи не стоит! Желательно достичь этого понимания в письменной/печатной форме. Здесь есть несколько заблуждений:
  • Клиент точно знает, чего хочет. НЕТ! Ни разу не встречал заказчика, который бы назвал четкие цели автоматизации и не "переобулся" бы 15 раз по ходу проекта! Необходимо выяснить текущие проблемы и ключевые показатели, которых хочет достичь заказчик. Детали выясняются в процессе, необходимо активно в нём участвовать и предлагать...
  • Путь решения слушать от заказчика не стоит совсем! Например: у нас есть Х баз разных. В одной кадры, в другой расчетчики, в третьей табель, ещё есть СКУД, интеграция с порталом и т.д. И ключевая цель: избавиться от лишних источников информации и мест ввода данных, проработать бизнес-процессы. Пути решения необходимо предложить самостоятельно, даже если у заказчика есть своё видение.
  • За данные отвечает заказчик, мы делаем только инструменты. Опять заблуждение! Если делается перенос данных, то Вы должны предложить пути по проверке данных и исправлению часто встречающихся ошибок. Кому нужен инструмент, который переносит мусор? В чём его польза для бизнеса?
  • Переносим ВСЁ, за ВСЕ года + ВСЕ начисления и налоги. Слыхали такой бред? Так делать нельзя. Нужна четкая концепция, в которой обозначены цели переноса данных (т.е. потребности заказчика) и пути их достижения (т.е. состав данных и используемые метаданные).
• Не делаем так, как просит заказчик! Заказчик может озвучить потребности, но не путь решения! Что, если заказчик предлагает грубо нарушить трудовой кодекс, Вам пойдёт на пользу выполнение такой задачи? Вы будете ею гордиться, впишете в резюме в самое заметное место?  Вряд ли! Необходимо настойчиво разъяснять заказчику, как делать правильно. Приводить примеры из Вашего опыта, предупреждать о последствиях, давать ссылки на законодательные акты и комментарии профессионалов к ним. 
• В бизнес-процессы нужно вмешиваться даже если нас не попросят. Что, если в нём есть настолько очевидные проблемы, решив которые можно упростить и ускорить работу? Проводите процесс обследования бизнес-процессов неявно! Делайте точечные предложения и обосновывайте их. 
• Настраиваем пользователей на то, что расчет выполняется автоматически, но проверять обязательно нужно! Программа сама посчитает зарплату, Вы же всё настроили? Зачем мне проверять, мне некогда!? Как только слышите такую фразу, необходимо предлагать реализовать контрольные процедуры, предупредить заказчика о неправильной позиции расчетчиков или кадровиков по поводу проверки данных. Результат таких действий в моей практике - перевод зарплаты давно уволенным на карточки, либо кратное увеличение выплаты в зависимости от переменной части зарплаты. Всё это является прямым убытком организации, т.к. вернуть средства почти нереально.
• С отчетностью аналогично. Часто звучат фразы: "Отчетность проверит налоговая программа!" "Там же есть контрольные соотношения!?" Такой подход грозит двумя простыми последствиями: штрафы и выездные внеплановые проверки.

Проверьте свою текущую работу. Какие из заблуждений для Вас сейчас оказались актуальными, какие пункты Вы не делаете сейчас? Востребованный специалист - это человек, способный приводить всё в порядок, убирать лишние звенья, снижать трудоёмкость и т.д. Умение автоматизировать бардак и плясать по дудку заказчика или РП не делает Вас востребованным специалистом!

Высокие требования к качеству. Подходы, благодаря которым достигается:

• Для понимания того, как выглядит правильный результат, необходимо изучить много информации. Это законодательство, бизнес-процессы, сценарии работы пользователей и программы, архитектура решения и т.д. Чем глубже мы изучим автоматизируемую область, чем лучше будет итоговый результат автоматизации. 
• Проектирование можно начинать только тогда, когда описаны все сценарии работы, по каждому сценарию расписаны тестовые примеры. Сценарий - это основа для проектирования и разработки!
• В процессе проектирования необходимо дополнительно смотреть код автоматизируемых объектов. Иногда достаточно внести несколько небольших изменений в существующий код. А вместо этого в задании написано создать новый документ/справочник/обработку и т.д. Не нужно создавать лишние объекты метаданных, особенно путём копирования типовых!
• Обсудите с разработчиком подход к решению задачи. Дайте ему свои рекомендации, послушайте его мнение. Делать это необходимо, когда реализация выполнена примерно на треть, максимум наполовину. Это позволит не переделывать всю реализацию, если разработчик выбрал неверный путь решения задачи.
• В процессе разработки соблюдайте общепринятые стандарты разработки фирмы 1С. Нарушение стандартов должно быть признаком профессионализма, и улучшать код. Часто это является проявлением разгильдяйства и нежелания работать по правилам. Это, в свою очередь, приводит к ошибкам в реализации.
• Проведите код-ревью. Даже свой код необходимо проверить на оптимальность и соблюдение стандартов. Если есть подчинённые, код-ревью проводить нужно обязательно! Часто в рамках этого этапа можно найти много ошибок. Как это делается, подробно описано в статье "Как читать чужой код Часть 1".
• Выполняйте тестирование только на реальных данных! Ни один даже самый грамотный консультант/аналитик не может учесть ВСЕ сценарии. Иногда проверяешь таблицу запроса, в ней 10 тыс. записей. И где-нибудь в середине таблицы 5 записей неверно заполнились. Получается, что эти 5 человек получат неверную зарплату! Если есть трудности с доступом к персональным данным, можно легко обфусцировать базу обработкой от 1С. 
• При тестировании проходим все описанные в начале сценарии. Ещё раз повторю, что пишут сценарии ДО разработки. После драки кулаками не машут. Сценарии станут основной для написания инструкций для пользователей, когда разработка уже завершена.
• Если Вы управляете процессом разработки, старайтесь не менять консультантов/аналитиков на этапах составления сценариев, тестирования, написания инструкций. Идёт потеря знаний при передаче задачи от одного к другому.

Проверьте свою работу. Нашли пункты, которых не делаете - добавьте их в свою работу, поднимите качество своего результата. Востребован работник, достигающий качественного результата. Выполнять это надо каждом проекте, даже если он маленький. Только тот, кто способен на протяжении 5-7 лет выполнять свою работу с упором на качество, а не на сроки/деньги/удовлетворенность заказчика, является востребованным. Ведь все клиенты хотят именно качества! Они просто не знают на старте, сколько стоит это качество и за какой временной промежуток его можно достичь! Помогите им в этом!

5. Интерес к проектам

В этом пункте отвечу на последний вопрос: "Зачем оставаться в этой предметной области? В чём интерес?". Приведу примеры некоторых решений. Более подробно примеры будут описаны в отдельной части статьи.

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

• "Несовершенство" бумажного документооборота. Иногда оно достигает сказочных размеров, как и предприятие, где встретилось (металлургический завод). Чтоб приняться на работу, кандидат проходил 3 стадии: Отдел кадров, будущий руководитель, медосмотр. Печаталась "карточка" кандидата, в ней от руки всё заполняли. Отдавали бумагу кандидату и отправляли в путешествие до самого дальнего цеха, длиною 1,5 км) На бумаге начальник ставил своё резюме и отправлял кандидата назад в отдел кадров. Далее печаталось "направление" на медосмотр. В нём также от руки всё заполнялось и человек уходил. Некоторые не возвращались, и это никто не контролировал. 

Решение:

-- Убрали полностью бумагу. Распечатывалось только направление на медосмотр, оно уже заполненное было! 

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

-- "Пропавших" обзванивали. Некоторые всё таки приходили и трудоустраивались

• Аналогичная проблема была с расчетом сдельной оплаты труда. Всё было на бумаге и от руки: выдача заданий, отметка результатов выполнения, расчет сделки. В расчетную бухгалтерию со всех концов завода приходили кипы сдельных нарядов))). Надо ли сказать, что некоторые наряды терялись, находились через пару недель.

Решение:

-- Реконструировали полностью бизнес-процесс. Включили в него ПДБ (планово-диспетчерское бюро) и БТЗ (бюро труда и занятости).

-- Первый отдел выдавал в печатном виде сменное задание мастеру смены. Мастер смены отмечал фактическое исполнение.

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

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

• Можно бесконечно рассказывать про организации, в которых отдел кадров работает в одной программе (не обязательно в 1С), а расчет зарплаты происходит в другой. Бывает ещё есть отдельно система для табельного учета, иногда она служит основанием для распределения затрат. На текущем проекте (начало 22 года) отдел кадров работает в Access, а потом ещё в УПП вносят информацию. Уверен, таких историй масса. Решение здесь может быть только одно: избавляться от лишних баз/программ, и вести учет в едином контуре. Какие проблемы возникают при таком подходе:
  • Теряются приказы. Чаще всего!
  • Неверные суммы плановых начислений
  • Не совпадают даты! Ведь приказ печатают из другой системы, а здесь можно и в дате опечататься! 
• Мы штатное расписание ведём в Excel! Часто слышите такую фразу? А зачем так делать? Что мешает использовать типовой функционал? В ЗУП 3 настоятельно рекомендую вести штатное расписание! Это сильно упрощает жизнь при оформлении кадровых приказов. В старых версиях приходилось сильно дорабатывать этот функционал и добавлять документ для оформления приказов по штатному расписанию.
• В момент запуска проекта, на предприятии полностью поменялась штатное расписание и подходы к расчету премиальной части. Для производственных цехов была придумана система распределения премиального фонда между всеми работниками какого либо участка. Т.к. участок не совпадал с подразделением, в которое по старому штатному расписанию принят сотрудник, руководители хотели кардинально перепахать штатное расписание. Вроде бы ничего необычного!? Но когда есть вредные условия труда и льготный стаж, необходимо провести большую работу по утверждению списка штатных единиц с вредными условиями труда и льготным стажем.

Решение:

-- Было предложено в штатном расписании и всех кадровых документах добавить новый разрез "Участок для премирования". 

-- Такое решение позволило не менять структуру штатного расписания. Ведь третий разрез был управленческим! 

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

Эти и другие ошибки в бизнес-процессах дают возможности:

• Прокачивать свои знания в предметной области. Необходимо глубоко вникнуть в процесс, в локальные нормативные документы, в законодательство. Эти 3 составляющие и являются основой знаний по предметной области.
• Использовать и совершенствовать те решения, которые появились на предыдущих проектах.
• "Влиять на чужие судьбы"). Ведь нормализуя процесс расчета зарплаты, неизбежно исправляются ошибки в расчете. Работники получают положенную по трудовому договору и законодательству зарплату. 
• Обеспечивается прозрачность расчета заработной платы. Работники перестают "бомбить" расчетную бухгалтерию в момент получения расчетных листков.

Напомню о наличии других полезных статей:

Часть 1. Общие вопросы. Доработка чужого кода. Code review.

Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации.

Часть 3. Разбор и доработка запросов

Часть 4. Программный интерфейс. Исправление чужих доработок.

Также напомню о статье про архитектора. Некоторые подходы, позволяющие решать сложные задачи, описаны в ней:

Кто такой архитектор. Редакция 2!