Часто спорим с коллегами, насколько важно (и насколько нужно) при внедрении системы учитывать требования локального законодательства. Кто-то считает, что ломать SAP под российскую специфику - преступление, кто-то считает, что надо делать из SAP аналог 1С. Каково ваше мнение?

Ответ должен быть в документе, описывающем функциональный объем конкретного проекта.

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

Ну тогда это вопрос маркетинговой политики компании-консультанта, которая продает проект

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

Если САП эти формы не сделал, значит их должна сделать консалтинговая компания, а трудозатраты должны быть учтены в сроках и бюджете проекта.

Российской (украинской) специфики должно быть по-максимуму, особенно если внедрение начинается где-то в районе FI-CO-NN-SD. Иначе в результате получаем очередной "зоопарк систем", и хорошо еще, если находятся грамотные программисты в каждой из них, которые могут обеспечить своевременную интеграцию (а то ведь обычно - пусть руками набивают). Да, за это должен заплатить клиент, потому как никакой аддон не покрывает и половины необходимого. Но при этом совершенно не надо "ломать SAP", он у нас все-таки довольно гибкий инструмент

Если "ломать", то наверное действительно лучше не надо. Хотя по идее нужно стремиться к "настраивать", а не ломать. Как сотрудник, отвечающий не только за внедрение, но и за последующую поддержку, я лично считаю, что чем меньше всяких доморощенных систем, тем лучше. Очень часто при внедрении подсчитывают только затраты на создание чего-то (например, интерфейса), но совершенно не думают о последующем геморрое (и расходах!) с поддержкой.

Есть единый источник информации (SAP) и всегда знаешь, откуда информация пришла и куда пошла. А так наворочают каких-то таблиц в Excel, накопируют чего-то (неправильно или не полностью), а потом сиди, разбирайся, почему у них "с SAP не сходится".

Я согласен, систем должно быть меньше. Но иногда возникают совсем странные требования, которые полностью меняют логику работы системы. Например, есть счет и к нему три оплаты. В каждой оплате необходимо в тексте выделить НДС, вы делаете это при помощи округления. В итоге сумма округленного НДС по трем оплатам на одну копейку отличается от НДС в счете. Для одних это не важно, другие готовы корректировать руками, для кого-то это повод написать ZF110, которая будет считывать сумму НДС и в последнем документе "добрасывать" копейку. Смысл последнего решения для меня недоступен.

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

Ну, это да. Поэтому на этапе gap analysis (а то и раньше) нужно решать, в каком направлении двигаться - забить вообще, изменить business process, как-то вручную обходить в стандарте или сделать ZF110. Если заказчик подсчитает, что им экономически выгоднее сделать ZF110, то и флаг им в руки.

Меня лично тоже от разных там ZF110 передергивает, но иногда приходится делать.