Переход с SAP на ЗУП: к чему нужно быть готовым

Задача: перейти с SAP HR на ЗУП 3.х. Выполнялась сложно, прошла с приключениями. Рассказываю к чему надо быть готовым, когда перед вами поставили такую, без сомнений, амбициозную задачу SAP на ЗУП

Автор Анна Елизарова. Источник

Задача: перевести организации численностью 3500 человек (производство) и 1700 человек (вахта, производство) с SAP HR на ЗУП 3.х.

Вот прям сразу рассказываю, чего от итогов перехода будут ждать пользователи систем и информации из систем:

1. Бизнес-процесс не поменялся ни на клик, все движения пользователей в точности такие же как были в SAP.
2. Вы перенесете вообще все данные за все время существования компании, включая то, что в базе источнике даже не хранилось (типа “мы вам дадим исторические данные, а вы там залейте”).
3. Не потребуется участие пользователей в обследовании.

Иначе говоря, “я не хочу ничего решать и в вашу эту странную желтую программу тоже не хочу”.

Стоит отметить, что наш SAP HR сильно кастомизирован под потребности бизнеса – его развивали годами, если не десятилетиями и он все это время был целевым. И так же хочу отметить, что в российских реалиях, SAP не может быть не кастомизирован ибо придуман был не про наше КДП, а вообще про другие процессы.

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

Да, это прям супер экстра мега обязательно. Это будет нудная череда встреч с бизнес-пользователями, их руководителями, по возможности, техническими специалистами SAP и другими людьми, которым тоже очень надо. Но это надо пережить, чтобы понять, что собственно надо-то.
Если говорить строго, то ЗУП полностью готов к работе, но… ох уж эти доработки под потребности.

Я гарантирую вам на тысячу процентов, что ни один специалист 1С и даже уникальный по нашим дням специалист-гибрид не сможет составить план перехода и эффективно перенести данные из SAP HR в 1С.  

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

Почему

Потому что между SAP HR и ЗУП 3.х пропасть. Одни и те же результаты достигаются очень-очень разными путями. Несмотря на то, что ЗУП, да и любая почти 1С, это такая тачка, за руль которой сел и поехал (если ты ее не админишь и не дорабатываешь, по крайней мере) пользователям очень сложно переключиться на незнакомую программу и логику. Пользователь, который не понимает логику своей системы не может дать внятные требования. Ниже расскажу почему их участие настолько важно.
 

Про различия

Различие, по смыслу, одно и ключевое: SAP (любой) – табличная база данных, а 1С (тоже любая) – ссылочная. Всё.
Да простят меня горячие поклонники SAP, но для не менее горячих поклонников 1С скажу еще более однозначно: SAP – это очень сложный и умный Acsess (если Вы не застали эпоху Acsess, то очень сложный и умный Exel).

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

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

Если 1С думает документами, помнит регистрами сведений и накопления, считает регистрами расчета, а справочники нужны буквально для того, как они называются – для хранения нормативно-справочной информации, то SAP всё это делает таблицами. Разными. Настроечными, расчетными, хранения, инфотипами. Селективные экраны SAP (по-нашему – формы) – это тоже таблицы. Даже для того, чтобы получить выходную (печатную) форму, нужно в определенной таблице (инфотипе) поставить определенный признак.

Кроме того, SAP принесет в жизнь специалиста 1С любого профиля такое новое и загадочное понятие как лимиты. Лимиты всего (применительно к управлению персоналом, например): сроков действия буквально чего угодно (то есть, не бывает, например, бессрочного перевода или трудового договора – так называемое “по бесконечность” это конечная дата 31.12.9999, хотя ЗУП считает, что наше время истечет 31.12.3999), отпусков (то, что в 1С работает правами на отпуск), начислений и надбавок и т.д..

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

Наконец, технические специалисты SAP, в большинстве своем, не универсалы. Кадры – одна группа, зарплата – другая группа и т.д.. Общая логика везде плюс-минус одна, но разные участки настраивают и дорабатывают разные люди.
 

Прекращаю растекаться мыслью по древу и рассказываю попунктно на что нужно обратить внимание при обследовании и подготовке переноса:

1. Штатное расписание. К нему надо отнестись очень внимательно.

То, что у нас живет только на позиции штатного расписания (далее – ПШР), в SAPе легко может жить “на человеке”. Языком конфигурации 1С – не в справочнике штатного расписания, а в кадровых документах. И, гарантирую, будут проблемы.

2. Плановые начисления. Вообще не факт, что в SAPе они будут соответствовать тому, что в штатной позиции или в мероприятии.

3. Справочники. Многие уже знают, что в SAP они есть, но по смыслу – это те же самые таблицы, которые содержат данные для разной сложности выпадающих списков. И между программными продуктами огромная разница.
Например, наш родной, от вендора, справочник трудовых функций имеет типовое для справочника ограничение символов в наименовании в 155 символов, а в SAP ограничения по символам нет. На практике это значит, что если вы не подумаете об этом заранее, многословные описания будут обрезаны начиная со 156-го символа.
Или тарифные группы. В ЗУПе есть справочники тарифных групп и разрядов, куда заводятся данные по группам и можно двумя путями подходить к ведению этих данных на ПШР (вести ПШР только в разрезе тарифных групп или в разрезе тарифных групп и разрядов (категорий)). В SAP тарифные группы могут быть назначены на штатной позиции, могут быть на человеке. И это надо учесть, до переноса (как минимум, включить настройку).

4. Охрана труда. Обязательно словами через рот надо проговорить где и как будут вестись данные по СОУТ – в справочнике должностей, на ПШР, в справочнике рабочих мест или полноценный учет СОУТ в подсистеме охрана труда. Это важно как для целей переноса, так и для бизнес-целей (формирования трудового договора в том числе).

5. Печатные формы. Если ЗУП только приходит в вашу организацию и ранее не дорабатывался, то огромным этапом работы станут печатные формы и их логика формирования. Гарантирую, что умный SAP «сам всё умеет и знает, зачем вам что-то объяснять». Зуб даю, не сам. На самом деле когда-то кто-то объяснил программе как именно она должна думать, чтобы дать желаемый результат в каждой отдельной печатной форме и тут без пользователей с экспертизой будет сильно сложнее, чем с ними.
 

Что надо объяснить пользователям ультимативно и гнуть свою линию до победного
 

1. ЗУП – это не SAP. Это прям другой программный продукт, он по-другому думает и много чего умеет и может. У проекта перехода нет цели сделать из ЗУП SAP.

Гарантирую, что первое, что от вас потребуют: «сделайте мне так же, как было». Не ведитесь. Стоит вам пойти на поводу у неопытного в 1С бизнеса, как вы не сможете потом это поддерживать.
Если вы проигнорируете этот совет, то разработчики будут учить программу делать ПШР срочными и назначать права на отпуск не с момента внесения данных и до новых изменений, а по число. Не надо так.

2. Отчеты. В SAP есть оперзапросы – по смыслу похоже на наш универсальный отчет, только с большим количеством источников. Все опытные пользователи и специалисты 1С знают, что если в базу что-то внесено, значит это что-то можно получить отчетом. Ваши будущие пользователи тоже должны проникнуться.

Идеально, получить ТЗ на самые популярные оперзапросы и настроить отчеты для примера. Верьте, это снимет очень много вопросов пользователей с обследования до старта работы и после него.

3. Один-к-одному и один-ко-множеству.

В SAP всё ведется один к одному. Без опций. Всегда. В 1С – наоборот.
Мой любимый пример – штатное расписание. С моей точки зрения, самый оптимальный вариант вести ШР – это плодить сущности (ПШР) в справочнике Штатное расписание и не плодить их во всех остальных. Штатные позиции в SAP всегда в единственном числе под конкретную ставку. Ну то есть не будет 40 одинаковых ставок условных менеджеров по клинингу в одной ПШР, будет 40 отдельных ПШР.
Если у вашего заказчика численность меньше 500 не поленитесь проанализировать штатное расписание и привести его к виду один-ко-множеству с учетом принципа одинаковости (с активным участием бизнеса, конечно). Вы будете себе благодарны.

4. Термины и определения. Одни и те же на звук термины значат в системах разное.

Пример: индивидуальные графики работы. В ЗУП это документ, который корректирует норму. В SAP HR, по смыслу, это – табель. *звуки из ералаша*
Вы реально можете часами одними и теми же словами говорить о разных вещах, разойтись довольными друг другом, а когда выпустите пользователей в эксплуатацию выяснить новости.
//кстати, в SAP вообще нет такого понятия как табель, только выходная форма, если ее доработали;

5. Объем переноса. Оптимально переносить последние 5 лет + данные за всю историю по действующим на дату переноса работникам.

Всё, пояснений не будет. Меньше можно, больше – не нужно.

6. Дата переноса. Когда-то я описывала переход с 2.5 на 3.х и говорила, что оптимально для всех процессов (кроме КДП, которому, в общем, всё равно) – переходить с 01.01 следующего налогового периода. Ничего не поменялось, все еще оптимально (с т.з. налогов и взносов).
    

Порядок действий для перехода
 

1.  Обучить будущих пользователей 1С работе с типовой конфигурацией ЗУП 3.х.

Если будете проводить обучение сами, то начните с начала, то есть с интерфейса. Да, вещи, которые понятны и очевидны для вас, не понятны и не очевидны для тех, кто никогда не работал с управляемыми формами.

1. Провести обследование.

Цель: понять бизнес-требования к системе. Если по-русски, то нужно получить внятные указания к тому, что именно нужно в системе. Контроли, печатные формы, отчеты, рассылки, уведомления, напоминания, особенности исчисления отпусков и прав на них, очередность списания отпусков, особенности расчета зарплаты, исчисления нормы времени по поводу расчета зарплаты и т.д. – список на сотни позиций.
Ожидаемый результат: список требований к системе.

2. Провести доработку ЗУП.

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

3. Разработать инструмент для перехода

Мы сделали расширение под это дело – огромный космолет. Но, в принципе, от объема переноса, можно хоть загрузкой из табличного документа развлекаться. Просто подумайте об инструменте и его возможностях заранее.

4. Провести тестовый перенос данных и запустить бизнес-пользователей пощупать.

Вот они те грабли, о которых я распинаюсь и почему настолько важно как обучить пользователей системы, так и всю дорогу требовать от них участия.
Знаете как перешли мои первые заказчики (1200 человек, производство)? У нас не было шага 0 и участие пользователей было довольно вялым в обследовании, так что вот как мы поняли потребности, так и сделали. Сделали тестовую загрузку данных и запустили пользователей в получившуюся “кошку” попробовать. Через месяц от начала пробного прогона мы спросили:
– Данные перенеслись?
– Перенеслись. – Ответили нам пользователи.
– Зарплата посчиталась?
– Посчиталась. – Ответили нам пользователи.
А вот о том, что данные перенеслись не в полном объеме, части функционала не хватает и зарплата посчиталась с косяками, они нам не сказали. Не со зла. Они просто не знали где смотреть и что проверять. Потому что нельзя просто взять и пересесть с SAPа на ЗУП.

5. По итогам тестового прогона доработать и докрутить выявившиеся косяки.
6. Провести боевую загрузку.
7. Проверить результаты.
8. Стартовать работу в ЗУП 3.х.
9. Проверить первые три расчета всего, начиная со штатного расписания и заканчивая отчетами.
10. Радоваться.