Архив форума

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

Здравствуйте, Коллеги!
Вопрос: Как лучше настроить Классификатор материалов, чтобы он отвечал задачам модулей SD и ММ?
Спасибо.

Жаль, что на этапе начала внедрения не подумали. С этого надо было начинать...
 
У нас используется СУС.
Что могу сказать... Тоже не подумали. Скоро год уж как доделываем, переделываем и адаптируем. Думаю, впереди еще не меньше года.
Весь вопрос не в том, SAP это или не SAP.
Вопрос в том, ложатся ли ваши технологические процессы, бизнес-процессы и заморочки на стандартные возможности и настройки SAP.
Если ложатся - то внедрять можно.
Если не ложатся - то нецелесообразно. По причине того, что SAP - это система, которая очень тяжело переделывается и очень дорого. И вообще каждый чих денег стоит и времени.
Нужно очень и очень тщательно изучить именно вопрос совместимости вашего бизнеса с SAP. И если несвоместим, то либо вы бизнес подстраиваете под SAP, либо лучше изучите другие WMS.
 
К сожалению, невозможно дать на Ваш вопрос однозначный ответ. Для этого нужно очень много знать про Вашу специфику.
 
Поясню на примере.
 
Когда начали внедрять SAP, то каждую новую партию производимого продукта было решено заводить в систему с новым номером материала. Так удобнее было бухгалтерии.
Когда внедрили СУС, то она честно начала размещать один и тот же продукт на разные ячейки склада. Так устроена информационная система. Она работает не с понятием "Продукт", а с номером материала. Склад начал распухать в арифметической прогрессии. Один и тот же товар лежал на разных ячейках, хотя должен по бизнес-логике на одной.
Пришлось это явление срочно гасить. Сначала путем ручных перемещений, а потом внедрением нехилых доработок. А это уже время и немалые деньги. До сих пор еще все это продолжается.
 
Это пример лишь одной заморочки. Их на самом деле много. Их причина всегда одна - отсутствие комплексного, консолидирующего подхода на этапе начала внедрения.
 
Повторю: трясите ваших SAP консультантов по поводу каждой мелочи в работе СУС на предмет того, как она ложится на ваш бизнес. Не поддавайтесь на уверения типа:
"Мы вас легко автоматизируем потому, что SAP - это суперсистема всех времен и народов".
SAP - это монстр. Это религия, точнее - секта.
Это гениальная машина по выколачиванию денег из клиентов на сам SAP и на армию его адептов.

Процитировано сообщение: Сергей Дьяков   от 22.11.2005 :: 16:11:03:

 

Я ж почему и сказал - думать о складе надо сразу, ДО того, как систему проектируют.
Посадить разные партии товара на "партии" в СУС - так надо было сделать. Но не сделали. Я ж говорю - бухгалтерия пересилила.
Партии у нас уже "используются" для других целей. Разные партии принадлежат разным собственникам продукции.
 

Не советую спрашивать у консультантов "Можно ли реализовать". Ответ получите "можно". Проблемы всплывут потом.
Ваш второй вариант более верный.
 
Определитесь, что вы хотите от СУС.
Если просто операции по приемке-размещению-отгрузке, это один подход.
Если, например, есть мечта использовать оптимизацию размещения или модуль ППМ (планирование потребности в материалах), то это уже совсем другая песня.
Если же хотите комплексное решение, включающее, например, полную оптимизацию (снабжения склада, размещения, перемещения, отгрузок), аналитику... то тут уже нужно очень сильно изучать, что и как.
 
SAP даже и в части простой операционной деятельности представляет из себя крайне замороченную и недружественную к пользователю систему. А как чуть сложнее - тут лучше, чтобы именно ваши бизнес-процессы как можно плотнее ложились на функциональность SAP. Иначе будет вам потом "счастье".
 
Я бы первое, чем озаботился - это изучением структуры вашего основного справочника товаров. Ибо это 80% успеха (либо геморроя).
Общий принцип должен быть такой. Один товар - один номер материала в SAP.
Товар - это некий набор потребительских свойств, однозначно идентифицирующийся клиентами как "отдельная товарная единица".
Если у вас это не так - задавайте вопрос консультантам, как именно они собираются из этого выкручиваться. И добивайтесь четкого ответа.
 
Второй вопрос - ППМ. Хотя он строго говоря к СУС не относится, но все потом хотят иметь оптимальные товарные запасы. В SAP несколько моделей ППМ. Подойдет ли к вашей специфике какая-то из них - это вам решать. Однозначно можно сказать следующее:
если у вас товар
- с рваным, нестабильным спросом
- с большой или нестабильной сезонностью
- с постоянным обновлением или заменой ассортимента
то SAP вам будет не помощник.
Идеальный товар для SAP - например, пиво, жвачка, либо строго планируемое производство (скажем, автомобили). Вот тут он все хорошо расчитает. Но тут и ума большого не надо.
 
 
 

Если у вас одна и та же модель (один и тот же товар с точки зрения ваших клиентов) заносится от разных поставщиков на разные номера материалов, то вам следует задаться вопросом:
а храниться эти "разные номера материалов" должны на одной ячейке или тоже на разных?
Если на разных - то все ок (хотя я сомневаюсь в целесообразности).
Если на одной ячейке склада, то вы уже попали, как минимум на полную переделку стандартных транзакций SAP по размещению. Так как работают они с номерами материалов и размещать вам все будут на разные ячейки.
 
(В этом случае вы попали на те же грабли, что и мы, а цепочка последствий этих граблей ой как велика, сами будете постоянно на нее напарываться)
 
Если у вас товар с постоянным обновлением ассортимента, то стандартные алгоритмы ППМ в SAP не обеспечат хорошей оптимизации снабжения склада. Они расчитаны прежде всего на высокостабильные товары - как по уровню продаж, так и по ассортименту. 90% работы ваши закупщики будут выполнять, как и прежде вручную, экспертным способом. Ситуацию усугубляет наличие двойных номеров. (надеюсь, понятно, почему усугубляет?)
 
Та же проблемы с двойными номерами материалов не позволит вам реализовать стандартными средствами оптимизацию отгрузок. Например, клиент заказал мясорубку, а она у вас имеется на складе в 2-х номерах, и лежат на разных ячейках. Вопрос: какую мясорубку выпишет вашему клиенту менеджер по продажам? №1 или №2? А какую НАДО выписать с точки зрения оптимизации? Это все очень большие вопросы. Хотите оптимизацию отгрузок - придется переписывать транзакции продажников.
 
Та же проблема двойных номеров не позволит стандартно оптимизировать размещение и перемещение.
 
В общем, у нас те же задачи - оптимизация снабжения, размещения, перемещения и отгрузок, и все они сейчас решаются полной заменой логистики SAP на самописную. То есть в SAP остаются из стандартных лишь чисто операционные вещи - проводки, накладные и т.п. Вся логистика так или иначе завязана на аналитику и на индивидуальные заморочки компании. Стандартные средства SAP тут бессильны.

[quote author=Сергей Дьяков  
Стандартные стратегии прекрасно работают, их вариантов достаточно чтобы запуститься и настроиться на свои складские технологии по максимуму, но в процессе работы как обычно хочется чего-то еще, еще и еще.... Ничего сложного там нет, все легко переписывается.
[/quote]
 
Кстати, Юлия, можно воочию видеть разницу в суждениях и подходах у консультантов SAP (Сергей) и у реальных пользователей (Андрей).
У нас то же самое. Первый ответ от консультантов всегда - "Все работает (сами дураки, не знаете, где что в SAP лежит), все настраивается, к вечеру все сделаем, никаких проблем и т.п.". Но такой ответ от них можно получить лишь тогда, когда пользователь ставит вопрос невнятно, не объясняя буквально до конца и в тонкостях, какой конечный результат он хочет и должен получить. Но если начинаешь ставить задачи очень конкретно и с доведением их именно до конечного результата, то все выливается в доп.разработки и большие сроки.
Обычный процесс такой.
1. SAP что-то внедряет и говорит, что все будет супер.
2. После внедрения пользователи плюются и говорят, что это совсем не то, что они ожидали, что все работает не так, как должно.
3. После изучения вопроса выясняется, что не учли какие-то нюансы и начинается переделка. Путем разработок, увы...
 
В случае SAPа непонимание между консультантами и пользователями - очень велико.
Предвижу возражения и даже готов допустить, что так оно и есть:
1. Нам не повезло с консультантами.
2. Нашим консультантам не повезло с пользователями.
 
Что поделаешь? Так уж жизнь повернулась...

 
P.S.
Сергей, ничего личного, просто так обстоят дела... Такова жизнь...

Процитировано сообщение: Сергей Дьяков   от 30.11.2005 :: 14:20:09:

 
Полностью согласен.
Уточню лишь, что архитектор не я.
Я занимаюсь разгребанием "архитектуры". На этапе проекта не участовал.
 
В Ваших словах содержится как раз причина того, что здание в итоге получается косое.
 
Кто архитекторы?
 
Архитектор - это человек или группа, которые должны видеть и проектировать здание целиком. У них должно быть абсолютно комплексное видение всего сооружения и абсолютное понимание всех взаимосвязанных кирпичей.
Нужно комплексное понимание всего бизнеса и всех процессов в компании. И понимание, как нужно и должно это реализовать в системе комплексно.
 
А теперь скажите, есть ли такие полноценные архитекторы
1. Среди консультантов SAP (IT-шников)?
2. Среди пользователей (даже если из них создали рабочую группу)?
 
Мой ответ такой.
Среди консультантов - нет. Среди внешних - тем более. Я имею в виду понимание конкретного бизнеса конкретной компании во всех мелочах.
Среди пользователей - тоже. Есть очень мало компаний, где можно создать рабочие группы по функциональному признаку, и они четко сформулируют требования, которые затем из отдельных сольются в общую систему, и система получится стройной и рабочей. Это компании с очень четко и жестко прописанными бизнес-процессами. Их мало. Тут Россия.

компоненты:  
SAP Business Information Warehouse (SAP BW) - Хранилище данных;
SAP Knowledge Management (SAP KM) – Управление знаниями;
SAP Strategic Enterprise Management (SAP SEM) – Стратегическое управление предприятием.