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

19.08.24

Бизнес-анализ - Внедрение изменений

Проект по переходу SAP на 1С – это не только перенос в 1С бизнес-процессов, которые ранее отражались в SAP. Системы отличаются кардинально – и подходом к внедрению, и работой в системе, и готовыми функциональными блоками, и интерфейсами. Расскажем о том, какие подводные камни ждут внедренцев на проектах перехода с 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.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Анализ бизнес-процессов Внедрение изменений Бесплатно (free)

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

23.09.2024    260    0    Radio_Analyst    1    

3

Agile Внедрение изменений Бесплатно (free)

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

13.09.2024    2184    0    glebushka    3    

7

Инструменты управления проектом Внедрение изменений Бесплатно (free)

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

12.09.2024    281    0    ermakovalekseyv    0    

2

Внедрение изменений Бесплатно (free)

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

11.09.2024    539    0    cybrat    0    

2

Внедрение изменений Бесплатно (free)

Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье.

21.08.2024    2396    52    Laya    3    

20

Оптимизация бизнес-процессов Взгляд со стороны Заказчика Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

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

13.08.2024    818    0    avermakov1986    5    

4

Внедрение изменений Бесплатно (free)

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

30.07.2024    861    0    MichaelMontrel    2    

6

Внедрение изменений Бесплатно (free)

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

16.07.2024    1215    0    Neti    2    

-1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1950534 19.08.24 12:23 Сейчас в теме
Рекламная статья Т1

Если вы реализуете функциональный гэп в 1% и кладете всю систему... хмм.. ну понятно всё))

То, как это написано, по сути означает что нет различий в проектах по переходу с SAP на 1С ERP или к примеру, с 1С 7.7 чтототампрограммистнамнаписал на 1С ERP.

Да, надо считать железо, собирать команду, собеседовать людей, переквалифицировать Саперов в 1Сников, но это надо делать всегда и везде.

Главное отличие SAP от 1С - SAP стоил раз в 10-20 дороже как ни считай, хоть на час работы, хоть на проект. Это приводило к тому, что SAP разрабатывали и внедряли люди с вышкой МГУ-МГТУ-МФТИ (условно говоря), а 1С разрабатывает и внедряет Вася из Ставрополя за 15 баксов в час)) и что он там разработает и внедрит - одному богу известно.

Печально это всё. Бизнес не выделяет ресурсы на тестирование не из-за вредности, а из-за отсутствия тех самых ресурсов. Бизнес сейчас сидит и плачет, глядя на всё это. Бизнес принуждаЮТ к переходу с того, что ещё может не окупилось, на что были потрачены иной раз миллиарды долларов (РЖД тому пример). А задача бизнеса - приносить прибыль акционеру, а не мигрировать с этих ваших SAPов.
vladimir.badaykin; dmitryada; acvatoris; +3 Ответить
2. user1559729 19.08.24 17:15 Сейчас в теме
(1) продолжайте кушать SAP...
3. user1950534 20.08.24 09:31 Сейчас в теме
4. user1559729 20.08.24 11:10 Сейчас в теме
(3) В (2) имел ввиду в кавычках - в смысле "потреблять/использовать". Прошу прощения, если что... Никого не хотел обидеть. Сам немного повзаимодействовал с SAP.
Если "того же" всмысле "желаемого" - то я желаю 1С, и поэтому она меня и так устраивает...
А вообще в (2) была отсылка к "бизнес принуждают". Можно узнать кто принуждает бизнес переходить на 1С? И почему именно на 1С?
6. user1950534 22.08.24 12:42 Сейчас в теме
(4) Кто "принуждает"? Вы серьезно?)) Телевизор последние 2 года включали хотя бы?)))
7. user1559729 22.08.24 12:50 Сейчас в теме
5. user2102077 21.08.24 07:45 Сейчас в теме
Начнем с ремарки, что когда SAP пришел, альтернативы у крупного бизнеса не было. 1C занимала свою нишу средних и мелких предприятий. Да и сейчас пригодность 1С для крупных корпораций под большим вопросом.
1. SAP никогда не стоил в 10-20 раз дороже 1С. На этапе внедрения в два-три раза максимум. Но если считать TCO на стратегическом горизонте, то 1С могла сравниться с SAP, а порой становилась дороже, и вот почему. Подход к внедрению, типа "чего изволите?", очень выгоден для 1C внедренцев, т.к. позволяет создать монстра, которого компания должна кормить и чем дальше тем больше. Причем бизнес-ценность хотелок пользователей оценивается по текущему моменту, если вообще оценивается. И вот через 5-7 лет вы уже сталкиваетесь с ситуацией, когда любое изменение бизнес-процесса требует очень значительных затрат. А учитывая повсеместное разгильдяйство, документирование разработок не ведется, что при нашей текучке кадров приводит к постоянному переписыванию крупных функциональных блоков. И вот ваша 1С уже и не такая дешевая и по стоимости всех затрат с момента покупки приблизилась, а то и превысила SAP, а бизнес процессы свои, кондовые, родненькие, но вот эффективные ли? Как правило, нет.
2. SAP привносит скелет типовых бизнес-процессов, который остается неизменным на стратегическом горизонте, обрастая различными дополнительными функциями, которые, как правило, сначала обсуждаются с бизнес-методологами, а затем внедряются, ведь здесь лучше семь раз измерить...
3. Ключевым элементом перехода с SAP на 1С становится методологическая работа, о которой автор не догадывается. Приготовьтесь... Самая главная опасность при переходе с одной системы на другую, это перенести неудачные решения, т.к. к ним привык бизнес, а удачные решения или требования похоронить/отсрочить, т.к. это не вписывается в стандартный функционал новой системы. Кто-то должен в этом разобраться и предложить выверенные или опробированные решения. Причем авторитетно предложить и обосновать. Провести быстро в разумном бюджете такую методологическую работу ни бизнес ни 1C внедренцы не могут. Поэтому к проработке процессов и функциональных требований нужно обязательно привлекать бизнес-методологов, что конечно удорожает этап проектирования, но в этом случае TCO системы оказывается ниже, а ценность для бизнеса выше.
eenik; vladimir.badaykin; +2 Ответить
8. пользователь 22.08.24 12:50
Сообщение было скрыто модератором.
...
Оставьте свое сообщение