О «дырах» в безопасности ERP систем

    Хотя мне больше нравится то название, которое я использовал у себя в жж. Но Хабр называет себя серьезным сайтом и название надо соответствующее.

    Компания Digital Security провела исследование безопасности ERP систем SAP и Oracle. Результаты исследования неутешительны для вышеназванных производителей. Однако Digital Security обнаружила всего лишь верхушку айсберга, не зная, как оно там в деталях, в производстве, так сказать. Я же хочу рассказать о причинах, по которым клиенты вышеназванных ERP-систем «живут» с этими проблемами почти десятилетиями и почему-то их не решают.

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

    Лет десять назад в ходу был анекдот про МИГи-29, которые у нас купили индусы. Купили в разобранном виде. Собирают, получается паровоз. Опять разбирают и снова собирают. Паровоз. Хоть ты тресни. Звонят нашим, так мол и так, не можем понять. А наши им – так там же написано в инструкции «собрать паровоз, а дальше напильником». Так вот, этот анекдот гораздо больше подходит ERP-системам, чем МИГам.

    Почему клиенты «живут» с этими проблемами вечно? Авторы исследования утверждают, что причиной тому – незнание настроек и их сложность. А вот я утверждаю, что нет.

    Представьте себя на месте клиента. Вы точно знаете, что у вас серьезные проблемы с безопасностью. Решить их можно, но для этого следует изучить «дремучие» настройки системы. Неужели вы не разберетесь с ними? Конечно, разберетесь. Но, к сожалению, дело совсем не в настройках. А в безбожно устаревших технологиях, как производства, так и внедрения erp-систем.

    Почти все производители идут одним и тем же путем. Выпускается нечто, что называют ERP-системой и продается клиентам. В реальности выпускается даже не полуфабракат, а нечто похуже, что без «напильника» работать не способно в принципе. Потом это «нечто» приносится на территорию заказчика и высыпается на пол. Затем туда приезжают разработчики и начинают «пилить».

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

    Кто-то может возразить мне – а почему тогда клиенты сами не решают эти проблемы, если они все равно кардинально меняют продукт, заставляя его работать. Но простите, зачем тогда вообще нужны такие производители ERP-систем, за которыми их собственные клиенты должны чистить все «баги»? Да и невозможно это, потому что далеко не все части ERP-систем открыты для изменений и изменить можно далеко не всё.

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

    Более того, примеров, когда компания продает ERP-систему, которой сама не пользуется, хоть отбавляй. Есть и компании, продающие и внедряющие сразу несколько ERP-систем. Как в этой ситуации осуществляется их поддержка, лучше спросить у самих клиентов.

    Иными словами все проблемы растут от технологий производства и внедрения ERP-систем, которые, как и безопасность находятся на уровне 10-летней давности, когда ERP-системы по сути разрабатывались на территории заказчика и строго индивидуально.

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

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

    Для оправдания отсталых технологий внедрения мне возразят стандартно и скажут, что все компании разные, у всех разные бизнес-процессы, поэтому избежать серьезного изменения кодов и схем данных не удастся. Классическая «отмазка», которой, кстати, пользуются еще и для того, чтобы вытянуть с клиента побольше денег на допиливание и достругивание «кастомизацию».

    Отвечаю. Я бы не писал этот материал, если бы не реализовал тиражируемые технологии у себя в компании.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 39

      –10
      Хорошо бы, чтобы авторы подобных материалов давали бы хотя бы краткий ликбез по основным терминам и абревиатурам. Статья интересная, но что такое ERP — так и не стало понятно
        +7
        Enterprise Resource Planning System — Система планирования ресурсов предприятия
          –4
          «Система планирования ресурсов предприятия» — это словосочетание напомнило название нашей кафедры «Автоматизация Систем Вычислительных Комплексов» или сокращенно «АСВК». Никто не делал тайны из того, что название кафедры было выдумано «для красоты звучания» и ничего конкретного не означало. Так и ваша расшифровка не приносит ясности — планирование ресурсов может быть как логистикой железнодорожных вагонов (если предприятие = угольный разрез), так и рассаживание программистов по проектам и комнатам (если предприятие = софтверная контора)
            +11
            Товарисч, не будьте занудой! Вики еще никто не отменял.
              0
              Все правильно! ERP — это давно девальвированный Бренд, которому дать структурное современное понятие практически невозможно. Поэтому это клеймо ставят на свои программы все кому не лень. Я потратил немало часов в интернете чтобы ответить на вопрос: какими признаками должна обладать система, чтобы быть ERP системой? Обнаружил что конкретика потеряна еще в 80-е годы прошлого века. И отказался использовать данную аббревиатуру для нашей системы. Кстати так поступают многие производители.
              А когда люди не могут конкретно ответить на вопрос они обычно и посылают в яндекс, википедию или еще куда подальше.
            +4
            Боюсь показаться неоригинальным, но: ru.wikipedia.org/wiki/ERP

            Сам часто в шоке от статей на Хабре (особенно, где представляется неведомый большинству смертных язык программирования со своими понятиями и терминами), кода без постоянного пересмотра документации или поиска в «любимом поисковике» невозможно читать.

            С другой стороны — здесь же не о художественной литературе или эротике с подробным описанием процесса пишут.
              +12
              Ну это всё-таки целый блог, который называется ERP-системы. В блоге 18 постов. Предлагаете в каждом давать расшифровку названия блога? :-)
                +10
                Если ты не можешь выяснить сам, что такое ERP, статья тебе не нужна.
                +13
                Топик ниочем.
                  0
                  согласен. хотелось бы услышать хотя бы в двух словах более развернутые комментарии по поводу двух озвученных в посте причин: устаревшие технологии производства и внедрения.

                  Насколько я знаю, SAP написан на java, в качестве БД может использовать и oracle, и db2 и вроде бы даже mssql. Эти «технологии» в общем-то не устаревшие. Или устаревший процесс производства самой системы SAP? В общем, непонятно, мне было бы интересно почитать об этом что-то содержательное.

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

                  И еще выскажу свое дилетантское мнение :) Мне лично непонятно в чем причины этих постоянных провалов с внедрением. Если абстрагироваться от качества внедренцев и связанных с этим проблем и иной системы бухгалтерского учета, то неужели теоретически так сложно автоматизировать производство? Или, например, автоматизировать весь страховой учет в страховой компании? Да, аспектов там много, работы тоже, но принципиальных преград я лично не вижу.
                    +3
                    И еще выскажу свое дилетантское мнение :) Мне лично непонятно в чем причины этих постоянных провалов с внедрением. Если абстрагироваться от качества внедренцев и связанных с этим проблем и иной системы бухгалтерского учета, то неужели теоретически так сложно автоматизировать производство? Или, например, автоматизировать весь страховой учет в страховой компании? Да, аспектов там много, работы тоже, но принципиальных преград я лично не вижу.

                    Причин много.

                    Курс автоматизации предприятий читать не буду, но в нескольких словах постараюсь ответить :-)
                    Автоматизация предприятия, внедрение ИС, состоит из ряда взаимосвязанных между собой стадий. При этом важно понимать, что внедрить ИС — это не значит купить соответствующее ПО и АО. Здесь так же происходят организационные изменения в компании, оптимизируются бизнес-процессы.
                    Перед непосредственным внедрением идет анализ предприятия, предпроектное обследование, описание нынешних бизнес-процессов и выстраивание новых, в которых будут устранены недостатки существующих.
                    Если стадия анализа была проведена некачественно, что-то описано некорректно или что-то не было учтено, в дальнейшем какой-то кусок внедренной системы может оказаться нежизнеспособным.

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

                    Ну или еще один пример. В процессе автоматизации у руководства компании попросту пропал интерес к проекту: здесь проект сразу обречен на провал. Если он и будет завершен (не прекратится его финансирование), то вряд ли он будет покрывать процесс компании, как это требуется.
                      0
                      спасибо за комментарий.

                      в общем я так и думал, что основные причины: некачественное обследование, нежелание руководства и тп нетехнические аспекты. Об этом я и говорил, что если от всего этого нетехнического абстрагироваться, то принципиальных проблем я в общем-то не вижу :)

                      получается, что сам софт, платформа (техническая часть), вроде как и не причем здесь. а причем в основном кадры: те, кто проводит обследование, те, кто руководит и тп. Например, я немного знаю как работают консультанты в больших российских компаниях. Такое впечатление, что все сделано для того, чтобы люди не могли достаточно хорошо разобраться в предметной области (то, что постоянно возникает такая проблема оставим за скобками — огромная текучка кадров), чтобы написать грамотное ТЗ, ну а дальше все понятно.
                        0
                        Другая причина: для автоматизации была выбрана неудачная технология. Допустим, происходит автоматизация службы кадров и вместо ПО, наиболее удовлетворяющего специфике отечественного кадрового учета, было взято что-то зарубежное, потому что это имеет крутой брэнд (например, модуль SAP HR).


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

                        Если какие-то части могут быть вполне успешно автоматизированы конкретным модулем того или иного продукта, то с некоторыми областями автоматизации возникают проблемы. Причем проблемы эти не всегда зависят от продукта. Это может быть связано с сохранением бизнес процессов Заказчика или интеграцией с зоопарком областей которые не вошли в проект (нельзя трогать, бюджет не позволяет и т.п.)
                          0
                          Да, со всем этим согласен.
                          У каждого решения есть своя методология, которая применяется при внедрение: у MS это Microsoft SureStep, у SAP'а что-то свое и т.п. Это все и сделано с целью, чтобы меньше налажать при автоматизации…
                        +9
                        Основная проблема: всем наср*ть.
                        Конкретно из преград:
                        — Люди сами не понимают, как они работают, т.е. у большинства работников нет видения бизнес-процесса, они больше привыкли «разруливать ситуации» и когда их загоняют в рамки ERP случается коллапс.
                        — Формализуют процессы (и пишут по ним ТЗ) не те, кто по ним работает, т.е. многие заказчики любят вкачать бабла и чтоб их не трогали, т.е. пусть приходит консультант, посмотрит как мы тут работаем, позадаёт вопросы, если надо, поставит задание технарям и те всё сделают, а потом внезапно оказывается, что в сделанном работать нельзя.
                        — Поголовная компьютерная неграмотность: люди (непосредственно юзеры системы) просто не умеют в ней работать, не понимают, что происходит при работе и, хуже всего, не хотят даже учиться. Они приходят на предприятие, заучивают порядок кнопок, которые нужно нажать до получения результата — и неотступно по нему действуют, не понимая, что происходит. А переучить такого человека, который несколько лет уже поработал в одной системе — это та ещё задачка :)
                        — Быдлокодеры у интеграторов. Особенно актуально в системах с ультранизким порогом вхождения типа 1С, конфиги для которого могут писать даже школьники. Какой там перехват исключений — даже переменные по-нормальному назвать не могут.
                          0
                          вот!!! именно это я и имел ввиду :)
                            –1
                            Насчет быдлокодерства не согласен. Я видел весьма дилетантский корявый код и хаотичные визуальные формы, которые спокойно работают годами. А также видел пальцатых сертифицированных разработчиков, у которых ВСЯ система (штрафы в ГАИ!!!) падает, если в поле поиска имени ввести непечатный символ.

                            Думаю, дело в культуре разработки. Когда один человек ставит задачи, второй пишет код, третий тщательно проверяет результат, а четвертый занимается внедрением и поддержкой. И у каждого есть определенные правила и стандарты, которые нужно соблюдать. А если все эти этапы делает один человек, то он будет подсознательно «под себя» работать.
                              +2
                              Приведённые вами примеры — это скорее исключения, чем правила. Любой хороший кодер всегда перехватывает исключения, фильтрует юзерский ввод, понятно и грамотно называет функции и переменные и пишет комменты. Сертификат — это, конечно, не показатель, хотя и хорошее подспорье при разгребании куч кандидатов.

                              С культурой разработки всё плачевно, да. В вашей схеме, по моему опыту, первый и четвёртый — это всегда один и тот же человек, третьего, обычно не существует (либо тот же человек, что первый и четвёртый), а вторых — дохренищщи, и каждый валяет во что горазд. Получается жуткая фигня, когда одни и те же функции в разных частях системы выглядят по-разному, называются по-разному и делаются по-разному, например чтобы попасть из списка в карточку в одной форме достаточно 2 раза кликнуть по элементу списка, во второй — нажать специальную кнопочку под списком, в третьей — нажать Enter. Что происходит с мозгом и нервными клетками юзера, который вынужден работать во всех трёх модулях — можно догадаться. Поэтому очень важно, чтобы был человек (назовём его QA), у которого есть целостное видение системы и который должен проводить ревью кода и выполняемых доработок, и иметь полномочия «продавливать» культуру в разработчиков. На деле это складывают на пиэма, а пиэм обычно занят согласованием бабла за выполненные работы и прочей не относящейся к разработке деятельностью.
                            0
                            Насколько я знаю, SAP написан на java, в качестве БД может использовать и oracle, и db2 и вроде бы даже mssql.

                            На сколько я знаю, в SAP есть какие-то штуки, написанные на Java. А в общем случае так нельзя сказать. Я вообще на вопрос, на чём написан SAP, получил ответ «на ABAP». Наверное, это недалеко от истины. И, кстати, вроде бы есть какой-то форк MySQL специально для SAP и он даже официально поддерживается.
                              0
                              вроде бы есть какой-то форк MySQL специально для SAP и он даже официально поддерживается.

                              Какие-то ужасы рассказываете. Оно же не поедет. Или вы про MaxDB? Так у MySQL эту игрушку давно отняли.
                                0
                                Верно. Строго говоря, именно продукт SAP ERP (то что называется R/3 или ECC) не содержит java, и полностью написан на ABAP. Есть другие продукты (например, портал, SRM), которые либо полностью работают на java, либо частично.
                                0
                                Есть еще и базовые аспекты. Их сложнее всего победить.
                                Я говорю о методологиях управления. Существует непреодолимая пропасть между программистами и специалистами управления предприятием или финансистами. Они друг друга не понимают. В результате берутся методологии (технологии) управления или учета десятилетиями вырабатываемые с использованием бумажного носителя информации и в точности копируются программно. Ну типа микроскопом гвозди забиваем.
                                Именно поэтому иногда использование автоматизированных систем все только усложняют и проекты внедрения проваливаются.
                                Мы пришли к выводу, что для создания тиражируемых решений автоматизации управления и учета нужно очень внимательно относится к базисным методологиям.

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

                                Реализуя эту табличку в базе данных нет необходимости иметь два поля, достаточно одно — сумма, а сумму положительный и отрицательных значений по отдельности мы получаем простым запросом. Это маленький пример о том, как влияют методы используемые на бумаге на структуру программы автоматизации. Таких моментов тысячи. Но в результате мы переносим и ограничения возможностей оперирования информацией с бумаги на компьютер. Потом с помощью супер возможностей компьютера пытаемся обойти эти ограничения. Программа получается сложной, настройки мудреными.
                              +5
                              Не так давно знакомый из крупной компании жаловался: «У нас отличные внутренние продукты, которые разрабатываются нами для нас самих уже второй десяток лет, но пару лет назад пришли ребята и сказали — внедряем [censored], и внедряют его до сих пор, отжирая миллионы каждый месяц». Кратко о причинах внедрения: «…Мы будем продаваться, и это в том числе увеличивает нашу оценочную стоимость».
                                0
                                Вовово, ибо воистину, да будет так. Полностью аналогичная ситуация у одного из наших клиентов.
                                  0
                                  «Внутренние продукты» очень не впечатляют аудиторов. Когда компания достигает солидной капитализации и хочет хороших инвесторов и больше профита, в том числе и при продаже — внутренние продукты не катят. Да и искать специалистов на их поддержку — то ещё удовольствие, особенно если там какая-нибудь база в FoxPro.
                                  +9
                                  Про индусов есть другая вариация этого анекдота.

                                  Стащили китайцы чертежи нашего новейшего истребителя. Собирают получается паровоз. Снова собирают, опять паровоз. Пришлось выкрасть генконструктора. Привозят. Он смотрит и говорит: «Сколько Вы украли?». Отвечают: «Вагон документации». Он им в ответ: «Ну так надо было еще 10 вагонов изменений украсть».

                                  Соль анекдота заключается не только в том, что в ERP-системах (и подобных им) много дырок. Эти системы настолько сложные, и бизнес-процессы поддерживаемые ими настолько необъятные, что обязательно где-нибудь найдется какая-нибудь дыра в организации поддержки этих самых бизнес-процессов и в организации самих этих бизнес-процессах на предприятии.

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

                                  Мы работаем с нашими крупными машиностроительными заводами уже более 10 лет (например Сушки, Тушки, Казанские вертолеты и т.п.). И не беремся за ERP, работаем только с PDM, используя очень аккуратно отдельные элементы ERP. Я не знаю как в других странах, а у нас в России есть несколько проблем:
                                  1. Это советское наследство в плохом смысле этого слова. То есть, отсталость, полуразрушенность предприятий, слабая элементная база, косность взглядов, разнесенность предприятий на очень большие территории (несколько городов например).
                                  2. Советское наследство в хорошем смысле этого слова. Собственные наработки в нашей стране по некоторым параметрам превосходят зарубежные или даже современные аналоги. Но они сделаны совершенно на другой концепции и на других стандартах. Очень сложно комбинировать и вливать в мировые стандарты, при этом не теряя ценные наработки.
                                  3. Финансирование во всех смыслах этого слова.
                                  Если взять из аналогов какой-нибудь боинг или аирбас, то там аналогичное положение вещей и индивидуальный подход к разработке.

                                  В качестве еще одного примера могу привести 1С. На сколько мне известно, сейчас они делают активные попытки внедрятся на одном из вертолетных заводов. Лучше бы они этого не делали. На заводе стоят срачики, похлеще сантабарбары. Ну не рассчитано у них работать несколькими сотнями цехов и номенклатурой в пару сотен тысяч изделий в рамках большого завода. Не особо получается пока, хотя я им желаю удачи.
                                    +5
                                    Тема дыр в безопасности не раскрыта. Заголовок не соответствует содержимому. Разрабатывать не устаревшее ПО для энтерпрайза нереально. От начала до внедрения проекта проходит невероятно большое количество времени. SaaS даже не получится сделать. Хотя тема интересная.
                                      0
                                      Статья написана для саморекламы. У автора задача продвинуть свой ERP продукт, ничего больше. Ладно, он еще научится.
                                      0
                                      Не понял. Причём тут изменение исходных кодов и «кастомизация»? В нормальных системах можно допиливать функционал путём написания модификаций во внутренней среде разработки, что никак не будет влиять на поддержку и совместимость с выпускаемыми производителем патчами.
                                        0
                                        Вы бы хотя бы конкретные примеры проблем разобрали что ли, а то и в правду как то неочём.
                                          +1
                                          Да, похоже, это PR-материал. Судя по ссылке ниже, дядька — директор компании, внедряющей самодельные ERP-решения, а у директоров на конкретику сильнейшая аллергия :)
                                            0
                                            Статейка то рекламная, типа покупайте АВА ерп нашу.
                                            –1
                                            На Хабре вроде как запрещен кросспостинг: pcmag.ru/columns/detail.php?ID=43993
                                              +2
                                              Это просто наглость: Александр Попов сделал кросспост Александра Попова.
                                              +4
                                              Прогон какой-то. Непонятно, про какие дыры идёт речь. Сравнение с автопромом неуместно. Автопром делает продукцию, которая устраивает 95% потребителей, допиливают свои тачилы очень небольшой процент. С ERP ситуация совершенно другая.
                                              Вы знакомы с демо-базой Cronus в NAV? Хоть одну компанию встречали, которая работает, используя такую модель бизнес-процессов? Особенно в России — тут вообще п-ц какой-то с организацией рабочих процессов и часто сами заказчики не могут объяснить, как они работают, а на встречах ещё начинают спорить с сами с собой о их же бизнес-процессах.
                                              Говно — оно в головах, а не в системе. В систему оно попадает из голов, и в залежах говнокода виноваты отнюдь не производители. И разгребать в большинстве случаев приходится не код производителя, а код внедренцев, которые писали, как им сказал заказчик.
                                                0
                                                Автор не имеет представления, о чем пишет.
                                                  +1
                                                  Про безопасность не скажу — не знаю, но про остальное подписываюсь под каждым словом. У нас SAP Business One. Пару лет его у нас на месте допиливали и в результате получили устаревшее внешне и внутренне необновляемое УГ.
                                                  Все данные в формах на сотни полей 8-10 пиксельным шрифтом. В БД таблицы по 300(!) столбцов, а от структуры некоторых волосы на затылке шевелятся. Сервер еле-еле 50 человек держит.
                                                    +1
                                                    Прочитал тему, честно говоря ничего не понял.
                                                    Являюсь консультантом уже 5-й год по внедрению ERP-систем, а именно SAP R/3.
                                                    По поводу других систем не скажу, но по поводу SAP свои 5 копеек вставлю.
                                                    Какие могут быть дыры:
                                                    1) Возможность подключения к системе
                                                    2) «Вредительство» пользователей
                                                    3) «Вредительство» консультантов/внедренцев
                                                    4) Вредительство третьих лиц
                                                    А теперь по пунктам.
                                                    1) Все вопросы уходят к админам, так как не смогли обеспечить необходимый уровень безопасности системы
                                                    2) В данном случае под вредительством понимается криворукость пользователей, в 99.9% случаев ничего серьезного пользователи не смогут натворить, все это исправляется, на что-то серьезное банально не должно быть полномочий
                                                    3) после окончания произведенных настроек в системе и передачи в продуктивную эксплуатацию начинается этап сопровождения, как правило у консультантов ограничиваются полномочия на выполнение операций
                                                    4) это в принципе довольно затруднительно и обусловлено архитектурой системного ландшафта.
                                                    Если кому-то интересно, могу рассказать в рамках своей компетенции.
                                                    З.Ы. По своему опыту могу сказать, что к допиливанию приходится прибегать в двух основных случаях:
                                                    1) в системе не реализован необходимый функционал
                                                    2) Функционал реализован криво или его объема недостаточно
                                                      0
                                                      Поддержу Вас.
                                                      Честно говоря, не вижу ничего страшного в том что ЕРП-системы дорабатываются и могут дорабатываться. В последнее время SAP реализовал функционал, с помощью которого клиенты могут очень успешно дорабатывать стандартные программы и не бояться при этом стандартных обновлений.
                                                      Возможность несанкционированного подключения к системе — это уже полностью решается админами, причем не только SAP-администраторами, а даже больше системными. Все остальное решается полномочиями в системе. Грамотный специалист с верным подходом не оставит пользователю/консультанту ни единого шанса сделать то, что ему не позволено.

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

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое