Переход с SAP на 1С. Опять наступаем на те же грабли?

Расскажу о такой теме, как переход с SAP на 1С:

• о подводных камнях, которые будут на проектах подобного типа;

• об особенностях SAP, которые вы обязательно встретите на подобных проектах;

• мы пройдемся вкратце по дорожной карте – я расскажу о подводных камнях, которые будут на каждом из этапов.

Немного о себе. Я Владислав Шелупин, работаю аналитиком в компании «Т1», у меня есть опыт проектов по переходу с SAP на 1С. При подготовке к докладу я провел опрос своих текущих и нынешних коллег – соединил все их знания и добавил в этот доклад.

Поскольку я выступаю в роли аналитика, многие вопросы буду рассматривать со своей колокольни – как функциональщик, а не как РП-шник.

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

• Мы будем говорить только про проекты по переходу с SAP на 1С или по переходу с одной системы на другую, которые очень сильно отличаются друг от друга.

• Клиент – это крупный бизнес, потому что средний и мелкий не потянет SAP финансово.

• Отрасль подойдет любая.

• Количество рабочих мест мы рассматриваем приблизительно от 300 и выше.

• Вид системы – это ERP-системы. В случае 1С – это 1С:ERP и УХ, в случае SAP – это SAP HANA.

Какие подводные камни ждут внедренцев?

Перед тем как перейти к первому блоку, где я расскажу про подводные камни, я бы хотел раскрыть такую тему: насколько проект должен быть гибким?

На слайде – два рисунка.

Слева я выписал виды проектов по PMI. Здесь есть четыре типа:

• Предиктивные – когда мы поставляем ценность целиком.

• Инкрементные – когда мы поставляем ценность кусочками, функциональными блоками или еще детальнее.

• Итеративные – если мы обновляем требования через прототипирование.

• Гибкие – думаю, они не нуждаются в описании.

Что подойдет для проектов по переходу с SAP на 1С?

• Гибкие подходы для таких проектов не подойдут, потому что гибкость – это про развитие продукта, а здесь мы создаем продукт.

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

• И от предиктивности нужно уходить в инкрементность. Нужно учитывать, что крупной компании всегда несколько уровней ответственности: гендиректор; CEO; руководители департаментов, отделов; есть филиальная структура. Информация сверху и снизу может отличаться. И зачастую на пресейлах вы можете услышать три тезиса.

  • «У нас все процессы зарегламентированы». При этом я неоднократно сталкивался, что на уровне исполнителей никто этим регламентом не пользуется. Либо регламент частично не актуален, либо еще что-то.

  • «У нас уже есть документация по SAP, возьмите ее и считайте, что моделирование проведено». Здесь тоже много подводных камней, чуть позже расскажу про это в докладе.

  • «Просто перенесите нам SAP в 1С». Но в учете компании всегда будут блоки функциональности, которые идут вне SAP, хотя должны попасть в функциональность 1С. Более детально об этом я тоже расскажу чуть позже.

Более-менее предиктивные проекты могут быть успешны только при тщательной проработке всех этих трех тезисов. Но на этом пути много подводных камней.

Справа на слайде представлен результат моего опроса – я опросил многих своих знакомых и коллег, которые занимались проектами по переходу с SAP на 1С.

• По оси Y оценивалось, насколько проект был инкрементным – насколько детализировалась поставка ценности в рамках проекта. 1 – по функциональным блокам. Выше – детальнее.

• По оси X – насколько проект был гибким. Здесь под гибкостью понимается количество обновлений ФТТ в рамках проекта.

• А размер точек оценивает эффективность проекта – сколько процентов функциональности продукта было принято бизнесом.

Результат опроса я выразил в этом графике. Выборка, конечно, маленькая, но это все, что я смог найти и собрать.

• По уровню инкрементности можно сказать, что все проекты по переходу с SAP на 1С поставляют ценность от функциональных блоков.

• Что касается гибкости, здесь можно наблюдать, что чем больше обновлений ФТТ будет, тем эффективнее будет проект – тем больше бизнес будет эту ценность принимать, а не отвергать.

Давайте перейдем к проблемам в подобных проектах.

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

Проблема возникает по двум основным причинам:

• Главная причина – что бизнес не выделяет ресурсы, чтобы провести нормальное тестирование. Тестирование нужно провести качественно, нужно выполнить закрытие месяца, сформировать финальные отчеты. Все должно сойтись, и только после этого можно будет пользоваться системой.

• При этом ответственные люди со стороны бизнеса – это зачастую не последние люди для компании. Это либо ответственные исполнители, либо руководители отделов, которые заточены на свою работу. Для людей от бизнеса, которые отвечают за результат этого этапа, проект внедрения – это что-то дополнительное, а не основная работа.

Какое здесь есть решение? На одном из проектов, в которых я участвовал, данная проблема была решена до ее появления.

• Мы на этапе предпроектного обследования зафиксировали в «Уставе проекта» не только описание ролей, но и объем трудозатрат, который данная роль должна выполнить в рамках каждого этапа.

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

• Конечно, «Устав проекта» – это не закон для бизнеса, но если мы заранее фиксируем в нем риски, мы доносим до бизнеса, что нужно будет выделить ресурсы. В моем случае от бизнеса на проект были привлечены помощники, которые помогли пройти этот этап.

Следующая проблема – это модификация окружения.

В понятие «окружение» я закладываю все, что окружает ERP:

• бизнес-приложения,

• СУБД,

• офисные приложения,

• железо и так далее.

Здесь важно, что ERP-система – это не сферический конь в вакууме, она связана с большим количеством приложений. С этим связан ряд проблем:

• Например, если мы вытаскиваем SAP и вместо нее устанавливаем 1С, мы натыкаемся на большой блок по интеграции – от этого никуда не уйти.

• А при замене SAP-овской СУБД на 1С-ную СУБД у нас, возможно, заменятся сотрудники, обслуживающие это окружение. Об этом нужно позаботиться заранее. Конечно, уволить и нанять человека – процесс недолгий, но это может занять определенное время. А нам нужно иметь специалистов к определенной дате – зачастую это либо приемосдаточные испытания, либо ввод в опытно-промышленную эксплуатацию.

• Параллельное использование, которое я выше упомянул, также накладывает дополнительную нагрузку на железо. Сервера могут не потянуть. Будет очень обидно, если мы все реализуем корректно, но система не потянет, и 1С будет просто тормозить.

Какое здесь есть решение?

• Со стороны заказчика – это детальное, полное, ответственное следование требованиям к аппаратному обеспечению.

• Со стороны исполнителя – это необходимость грамотно указывать эти требования.

На одном из моих проектов руководитель проекта со стороны исполнителя даже сам контролировал процесс закупки железа. В корпорациях закупки зачастую могут идти очень долго – через специальные процедуры закупок и согласования. И РП-шник со стороны исполнителя должен это контролировать, даже если он не является сотрудником компании-заказчика.

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

1. Каждый функциональный блок имеет свою специфику. Желательно разделить проект по переходу на блоки, и на каждый блок смотреть как на отдельный маленький проект, реализуя каскадную последовательность их выполнения. Например, интеграция всегда должна идти в конце, потому что ее не выполнить без реализованной функциональности других блоков. Или бывают некоторые задачи бюджетирования, которые не решить без реализованных блоков из бухгалтерии и так далее. Вырисовывается некая последовательность – каскадность. Мы должны доносить до заказчика, что для успешной реализации проекта должна быть определенная последовательность – нельзя делать все в одной куче одновременно. Конечно, ситуации бывают разные, иногда все зависит от денег или каких-то политических моментов, но эту информацию нужно доносить.

2. Заложить время на разработку дополнительной функциональности. Не вся функциональность SAP покрывается 1С – некоторые возможности нужно дорабатывать. Бывают такие моменты, когда у нас со стороны SAP маленький кусочек – около 1% от общей функциональности – не реализуется в 1С. Но здесь не нужно радоваться, потому что этот 1% может нанести такой аффект в систему при разработке и внедрении, что объем дорабатываемой функциональности получится намного больше. Это надо иметь в виду.

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

4. Коммуникация с вендором. Если мы наши ошибки будем отправлять напрямую вендору, это даст нам отличный способ сэкономить время. Важно: чтобы наши запросы реализовывались быстро, корректно и не вызывали проблем, на эту задачу нужно выделить отдельного менеджера. Но менеджера мы сможем выделить только если наш проект будет более-менее глобальный, большой и стратегический. Зато таким способом мы сможем экономить время.

В чем отличие мировосприятия Сапера и 1С-ника?

Немного отвлечемся от темы управления проектами – я расскажу о своих мыслях по поводу того, чем отличается мировосприятие внедренцев SAP и 1С.

Системы SAP и 1С – довольно разные. Они отличаются как подходом к реализации (у саперов свои методики), так и маркетингом, работой в системе, интерфейсами и т.д. Это все накладывает свой отпечаток и на консультантов-аналитиков, которые занимаются этими вопросами:

• SAP довольно стар, продуман, но он не гибок – прогиб сапера стоит очень дорого для компании. Прогиб 1С-ника – дешевле.

• SAP говорит: «Наша система идеальна, и вы подстроитесь под нашу систему», а 1С говорит: «Наша ERP-система может все, и мы подстроимся под бизнес»,

• Саперы – это более прямой типаж. А для 1С-ника важна гибкость, важно находить проблемы у клиентов и находить их решение,.

• SAP-рынок, если брать Россию – это рынок продавца. А 1С-рынок – это больше рынок покупателя.

Лично мое мнение, что бизнес-ценность, подставляемая 1С и SAP, приблизительно одинаковая. Но SAP стоит намного дороже. SAP – это корпоративное ПО, и до тренда с импортозамещением был такой интересный кейс, что компании перед публикацией ценных бумаг на международных биржах проводили внедрение SAP в головной организации, чтобы произвести впечатление на потенциальных инвесторов . Для этого и нужен SAP.

Дорожная карта

Быстро пробегусь по дорожной карте, расскажу, на что нужно обратить внимание.

Первый этап проекта по переходу с SAP на 1С – это предпроектное обследование.

• Главная цель предпроектного обследования – сформировать из неосознанных бизнес-требований осознанные требования ФТТ.

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

Следующий этап проекта – это моделирование. Цель моделирования – это формирование логической и физической модели.

Результатами этапа моделирования должны быть:

• модель процессов;

• модель функций;

• модель данных;

• модель решений;

• модель границ;

• модель состояний.

Какие на этапе моделирования есть риски:

• У SAP есть специфика: пользователи SAP очень много работают в Excel и других сторонних программах. Так происходит, потому что SAP довольно негибкий, и хотелки, которые есть у пользователей SAP, трудно реализуются. Они накапливаются в бизнесе, и в один неприятный момент могут как лавина обрушиться на наш этап моделирования – создать много функциональных разрывов.
  Если пользователь подходит к разработчику SAP и говорит: «Я хочу, чтобы вы мне сделали такую-то кнопку, взяли данные оттуда, вставили туда, перенесли, создали здесь график» – со стороны SAP это вылезет в большой чек, поэтому зачастую в SAP хотелки пользователя не реализуются. А когда вместо SAP внедряется 1С, до бизнеса не сразу доходит, что все эти хотелки можно реализовать, поэтому нужно самим клещами вытаскивать эту информацию из бизнеса, чтобы потом в ненужный момент она не обрушилась на нас.
  Мы должны понимать, что переход с SAP на 1С – это не только SAP-овская функциональность, но и дополнительная функциональность, которая есть в бизнесе. Мы должны это понимать, потому что это создаёт больший объём.

• Дальше – наличие в SAP модулей, которых нет в 1С. Многие модули SAP покрываются в 1С не полностью. Когда мы реализуем какую-то функциональность SAP в 1С, это может дать аффект на другие блоки, на всю систему. Мы можем очень сильно поломать 1С. Не нужно радоваться, когда мы увидим, что 99% функциональности покрывается SAP – этот 1% может очень сильно нам помешать.

• И готовая документация SAP. Саперы делают документацию очень качественно, красиво, хорошо – к этому никаких замечаний нет. И на проектах заказчик выкатывает эту документацию как готовую модель. Но особо радоваться этому не стоит, потому что всю эту документацию нужно еще обработать. Это гигантские талмуды технического текста, их нужно прочитать, добавить модули, которые не покрываются функциональностью 1С, все это встроить и создать новую архитектуру. По сути, всю эту документацию нужно будет переделать. И даже если она и поможет нам сократить этап моделирования, то не на 50%, а максимум на 5%.

Дальше я хочу обратить внимание на два момента, которые очень важны на проектах по переходу с SAP на 1С.

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

Что будет, если мы не сделаем модель данных:

1. Несоответствие реквизитов. Представьте ситуацию: вы архитектор и проектируете этаж – на этаже 2 комнаты. И вы так спроектировали этаж, что окно в одной комнате выходит в стену другой комнаты. Если вы не сформируете корректную модель данных, то же самое будет в вашей системе.

2. Трата времени на выверку, потому что ERP-система – это большое количество блоков. К каждому блоку есть свои требования. При этом требования для разных блоков могут относиться к одному и тому же документу. Поэтому на глобальных проектах по внедрению ERP-систем нужно всегда соблюдать порядок в системе – чтобы был порядок с нашими данными, с нашим фундаментом.

Для построения модели данных можно использовать следующие инструменты:

• Я предлагаю использовать СППР. Я – фанат СППР.

• Но те, кто не понял достоинства СППР, обычно используют Excel.

Отдельно отмечу, что модель данных должна быть единой на весь проект. Если делать отдельные модели данных по каждому функциональному блоку – ждите беды. Придется их объединять, соединять, вы потратите гигантское количество времени.

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

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

Залог успеха – ресурсы, сотрудничество и мотивация

Подведу итог моего доклада.

Мы можем реализовывать проекты по переходу SAP на 1С под ключ либо полностью довериться заказчику. Но и в первом, и во втором варианте будут проблемы:

• В первом варианте мы не слышим бизнес.

• Во втором варианте бизнес судит со своей колокольни – с колокольни SAP.

• Идеальный вариант – когда мы оба работаем над проектом. Но в этом случае со стороны топ-менеджмента заказчика должна быть проведена работа по вовлечению бизнеса в процесс – бизнес должен быть замотивирован. Как это сделать – это уже тема для отдельного доклада.

Краткие выводы из того, на что нужно обращать внимание:

1. Параллельная работа в старой и новой системе. Здесь будет большая нагрузка на железо и на бизнес. У бизнеса будет не хватать ресурсов. Бизнес должен быть к этому готов.

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

3. Документация по SAP – это не модель, не нужно надеяться, что она кардинально сократит блок моделирования. Она нам, конечно, хорошо поможет, но не настолько, как это рекламируется.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.