Комментарии 39
Хорошо бы, чтобы авторы подобных материалов давали бы хотя бы краткий ликбез по основным терминам и абревиатурам. Статья интересная, но что такое ERP — так и не стало понятно
Enterprise Resource Planning System — Система планирования ресурсов предприятия
«Система планирования ресурсов предприятия» — это словосочетание напомнило название нашей кафедры «Автоматизация Систем Вычислительных Комплексов» или сокращенно «АСВК». Никто не делал тайны из того, что название кафедры было выдумано «для красоты звучания» и ничего конкретного не означало. Так и ваша расшифровка не приносит ясности — планирование ресурсов может быть как логистикой железнодорожных вагонов (если предприятие = угольный разрез), так и рассаживание программистов по проектам и комнатам (если предприятие = софтверная контора)
Товарисч, не будьте занудой! Вики еще никто не отменял.
Все правильно! ERP — это давно девальвированный Бренд, которому дать структурное современное понятие практически невозможно. Поэтому это клеймо ставят на свои программы все кому не лень. Я потратил немало часов в интернете чтобы ответить на вопрос: какими признаками должна обладать система, чтобы быть ERP системой? Обнаружил что конкретика потеряна еще в 80-е годы прошлого века. И отказался использовать данную аббревиатуру для нашей системы. Кстати так поступают многие производители.
А когда люди не могут конкретно ответить на вопрос они обычно и посылают в яндекс, википедию или еще куда подальше.
А когда люди не могут конкретно ответить на вопрос они обычно и посылают в яндекс, википедию или еще куда подальше.
Боюсь показаться неоригинальным, но: ru.wikipedia.org/wiki/ERP
Сам часто в шоке от статей на Хабре (особенно, где представляется неведомый большинству смертных язык программирования со своими понятиями и терминами), кода без постоянного пересмотра документации или поиска в «любимом поисковике» невозможно читать.
С другой стороны — здесь же не о художественной литературе или эротике с подробным описанием процесса пишут.
Сам часто в шоке от статей на Хабре (особенно, где представляется неведомый большинству смертных язык программирования со своими понятиями и терминами), кода без постоянного пересмотра документации или поиска в «любимом поисковике» невозможно читать.
С другой стороны — здесь же не о художественной литературе или эротике с подробным описанием процесса пишут.
Ну это всё-таки целый блог, который называется ERP-системы. В блоге 18 постов. Предлагаете в каждом давать расшифровку названия блога? :-)
Если ты не можешь выяснить сам, что такое ERP, статья тебе не нужна.
Топик ниочем.
согласен. хотелось бы услышать хотя бы в двух словах более развернутые комментарии по поводу двух озвученных в посте причин: устаревшие технологии производства и внедрения.
Насколько я знаю, SAP написан на java, в качестве БД может использовать и oracle, и db2 и вроде бы даже mssql. Эти «технологии» в общем-то не устаревшие. Или устаревший процесс производства самой системы SAP? В общем, непонятно, мне было бы интересно почитать об этом что-то содержательное.
А вот то, что у всех проблемы с этими системами, результатом внедрения является уникальный продукт и тп — это говорят постоянно. В связи с этим еще один вопрос: это только в России так или на Диком Западе аналогичная ситуация?
И еще выскажу свое дилетантское мнение :) Мне лично непонятно в чем причины этих постоянных провалов с внедрением. Если абстрагироваться от качества внедренцев и связанных с этим проблем и иной системы бухгалтерского учета, то неужели теоретически так сложно автоматизировать производство? Или, например, автоматизировать весь страховой учет в страховой компании? Да, аспектов там много, работы тоже, но принципиальных преград я лично не вижу.
Насколько я знаю, SAP написан на java, в качестве БД может использовать и oracle, и db2 и вроде бы даже mssql. Эти «технологии» в общем-то не устаревшие. Или устаревший процесс производства самой системы SAP? В общем, непонятно, мне было бы интересно почитать об этом что-то содержательное.
А вот то, что у всех проблемы с этими системами, результатом внедрения является уникальный продукт и тп — это говорят постоянно. В связи с этим еще один вопрос: это только в России так или на Диком Западе аналогичная ситуация?
И еще выскажу свое дилетантское мнение :) Мне лично непонятно в чем причины этих постоянных провалов с внедрением. Если абстрагироваться от качества внедренцев и связанных с этим проблем и иной системы бухгалтерского учета, то неужели теоретически так сложно автоматизировать производство? Или, например, автоматизировать весь страховой учет в страховой компании? Да, аспектов там много, работы тоже, но принципиальных преград я лично не вижу.
И еще выскажу свое дилетантское мнение :) Мне лично непонятно в чем причины этих постоянных провалов с внедрением. Если абстрагироваться от качества внедренцев и связанных с этим проблем и иной системы бухгалтерского учета, то неужели теоретически так сложно автоматизировать производство? Или, например, автоматизировать весь страховой учет в страховой компании? Да, аспектов там много, работы тоже, но принципиальных преград я лично не вижу.
Причин много.
Курс автоматизации предприятий читать не буду, но в нескольких словах постараюсь ответить :-)
Автоматизация предприятия, внедрение ИС, состоит из ряда взаимосвязанных между собой стадий. При этом важно понимать, что внедрить ИС — это не значит купить соответствующее ПО и АО. Здесь так же происходят организационные изменения в компании, оптимизируются бизнес-процессы.
Перед непосредственным внедрением идет анализ предприятия, предпроектное обследование, описание нынешних бизнес-процессов и выстраивание новых, в которых будут устранены недостатки существующих.
Если стадия анализа была проведена некачественно, что-то описано некорректно или что-то не было учтено, в дальнейшем какой-то кусок внедренной системы может оказаться нежизнеспособным.
Другая причина: для автоматизации была выбрана неудачная технология. Допустим, происходит автоматизация службы кадров и вместо ПО, наиболее удовлетворяющего специфике отечественного кадрового учета, было взято что-то зарубежное, потому что это имеет крутой брэнд (например, модуль SAP HR).
Ну или еще один пример. В процессе автоматизации у руководства компании попросту пропал интерес к проекту: здесь проект сразу обречен на провал. Если он и будет завершен (не прекратится его финансирование), то вряд ли он будет покрывать процесс компании, как это требуется.
спасибо за комментарий.
в общем я так и думал, что основные причины: некачественное обследование, нежелание руководства и тп нетехнические аспекты. Об этом я и говорил, что если от всего этого нетехнического абстрагироваться, то принципиальных проблем я в общем-то не вижу :)
получается, что сам софт, платформа (техническая часть), вроде как и не причем здесь. а причем в основном кадры: те, кто проводит обследование, те, кто руководит и тп. Например, я немного знаю как работают консультанты в больших российских компаниях. Такое впечатление, что все сделано для того, чтобы люди не могли достаточно хорошо разобраться в предметной области (то, что постоянно возникает такая проблема оставим за скобками — огромная текучка кадров), чтобы написать грамотное ТЗ, ну а дальше все понятно.
в общем я так и думал, что основные причины: некачественное обследование, нежелание руководства и тп нетехнические аспекты. Об этом я и говорил, что если от всего этого нетехнического абстрагироваться, то принципиальных проблем я в общем-то не вижу :)
получается, что сам софт, платформа (техническая часть), вроде как и не причем здесь. а причем в основном кадры: те, кто проводит обследование, те, кто руководит и тп. Например, я немного знаю как работают консультанты в больших российских компаниях. Такое впечатление, что все сделано для того, чтобы люди не могли достаточно хорошо разобраться в предметной области (то, что постоянно возникает такая проблема оставим за скобками — огромная текучка кадров), чтобы написать грамотное ТЗ, ну а дальше все понятно.
Другая причина: для автоматизации была выбрана неудачная технология. Допустим, происходит автоматизация службы кадров и вместо ПО, наиболее удовлетворяющего специфике отечественного кадрового учета, было взято что-то зарубежное, потому что это имеет крутой брэнд (например, модуль SAP HR).
Скажем так, что когда происходит обследование, то предложение к автоматизации выстраивается на основании тех продуктов, которые может предложить компания Исполнитель. Но даже если компания может предоставить несколько различных продуктов (SAP, BAAN, Oracle, Cognos, 1C), то обследование чаще всего делается от «лица» конкретного продукта. И его начинают продвигать в системных проектах, тендерах… При этом редко когда предлагают комплексное решение, которое может оптимально подойти в данном случае.
Если какие-то части могут быть вполне успешно автоматизированы конкретным модулем того или иного продукта, то с некоторыми областями автоматизации возникают проблемы. Причем проблемы эти не всегда зависят от продукта. Это может быть связано с сохранением бизнес процессов Заказчика или интеграцией с зоопарком областей которые не вошли в проект (нельзя трогать, бюджет не позволяет и т.п.)
Основная проблема: всем наср*ть.
Конкретно из преград:
— Люди сами не понимают, как они работают, т.е. у большинства работников нет видения бизнес-процесса, они больше привыкли «разруливать ситуации» и когда их загоняют в рамки ERP случается коллапс.
— Формализуют процессы (и пишут по ним ТЗ) не те, кто по ним работает, т.е. многие заказчики любят вкачать бабла и чтоб их не трогали, т.е. пусть приходит консультант, посмотрит как мы тут работаем, позадаёт вопросы, если надо, поставит задание технарям и те всё сделают, а потом внезапно оказывается, что в сделанном работать нельзя.
— Поголовная компьютерная неграмотность: люди (непосредственно юзеры системы) просто не умеют в ней работать, не понимают, что происходит при работе и, хуже всего, не хотят даже учиться. Они приходят на предприятие, заучивают порядок кнопок, которые нужно нажать до получения результата — и неотступно по нему действуют, не понимая, что происходит. А переучить такого человека, который несколько лет уже поработал в одной системе — это та ещё задачка :)
— Быдлокодеры у интеграторов. Особенно актуально в системах с ультранизким порогом вхождения типа 1С, конфиги для которого могут писать даже школьники. Какой там перехват исключений — даже переменные по-нормальному назвать не могут.
Конкретно из преград:
— Люди сами не понимают, как они работают, т.е. у большинства работников нет видения бизнес-процесса, они больше привыкли «разруливать ситуации» и когда их загоняют в рамки ERP случается коллапс.
— Формализуют процессы (и пишут по ним ТЗ) не те, кто по ним работает, т.е. многие заказчики любят вкачать бабла и чтоб их не трогали, т.е. пусть приходит консультант, посмотрит как мы тут работаем, позадаёт вопросы, если надо, поставит задание технарям и те всё сделают, а потом внезапно оказывается, что в сделанном работать нельзя.
— Поголовная компьютерная неграмотность: люди (непосредственно юзеры системы) просто не умеют в ней работать, не понимают, что происходит при работе и, хуже всего, не хотят даже учиться. Они приходят на предприятие, заучивают порядок кнопок, которые нужно нажать до получения результата — и неотступно по нему действуют, не понимая, что происходит. А переучить такого человека, который несколько лет уже поработал в одной системе — это та ещё задачка :)
— Быдлокодеры у интеграторов. Особенно актуально в системах с ультранизким порогом вхождения типа 1С, конфиги для которого могут писать даже школьники. Какой там перехват исключений — даже переменные по-нормальному назвать не могут.
вот!!! именно это я и имел ввиду :)
Насчет быдлокодерства не согласен. Я видел весьма дилетантский корявый код и хаотичные визуальные формы, которые спокойно работают годами. А также видел пальцатых сертифицированных разработчиков, у которых ВСЯ система (штрафы в ГАИ!!!) падает, если в поле поиска имени ввести непечатный символ.
Думаю, дело в культуре разработки. Когда один человек ставит задачи, второй пишет код, третий тщательно проверяет результат, а четвертый занимается внедрением и поддержкой. И у каждого есть определенные правила и стандарты, которые нужно соблюдать. А если все эти этапы делает один человек, то он будет подсознательно «под себя» работать.
Думаю, дело в культуре разработки. Когда один человек ставит задачи, второй пишет код, третий тщательно проверяет результат, а четвертый занимается внедрением и поддержкой. И у каждого есть определенные правила и стандарты, которые нужно соблюдать. А если все эти этапы делает один человек, то он будет подсознательно «под себя» работать.
Приведённые вами примеры — это скорее исключения, чем правила. Любой хороший кодер всегда перехватывает исключения, фильтрует юзерский ввод, понятно и грамотно называет функции и переменные и пишет комменты. Сертификат — это, конечно, не показатель, хотя и хорошее подспорье при разгребании куч кандидатов.
С культурой разработки всё плачевно, да. В вашей схеме, по моему опыту, первый и четвёртый — это всегда один и тот же человек, третьего, обычно не существует (либо тот же человек, что первый и четвёртый), а вторых — дохренищщи, и каждый валяет во что горазд. Получается жуткая фигня, когда одни и те же функции в разных частях системы выглядят по-разному, называются по-разному и делаются по-разному, например чтобы попасть из списка в карточку в одной форме достаточно 2 раза кликнуть по элементу списка, во второй — нажать специальную кнопочку под списком, в третьей — нажать Enter. Что происходит с мозгом и нервными клетками юзера, который вынужден работать во всех трёх модулях — можно догадаться. Поэтому очень важно, чтобы был человек (назовём его QA), у которого есть целостное видение системы и который должен проводить ревью кода и выполняемых доработок, и иметь полномочия «продавливать» культуру в разработчиков. На деле это складывают на пиэма, а пиэм обычно занят согласованием бабла за выполненные работы и прочей не относящейся к разработке деятельностью.
С культурой разработки всё плачевно, да. В вашей схеме, по моему опыту, первый и четвёртый — это всегда один и тот же человек, третьего, обычно не существует (либо тот же человек, что первый и четвёртый), а вторых — дохренищщи, и каждый валяет во что горазд. Получается жуткая фигня, когда одни и те же функции в разных частях системы выглядят по-разному, называются по-разному и делаются по-разному, например чтобы попасть из списка в карточку в одной форме достаточно 2 раза кликнуть по элементу списка, во второй — нажать специальную кнопочку под списком, в третьей — нажать Enter. Что происходит с мозгом и нервными клетками юзера, который вынужден работать во всех трёх модулях — можно догадаться. Поэтому очень важно, чтобы был человек (назовём его QA), у которого есть целостное видение системы и который должен проводить ревью кода и выполняемых доработок, и иметь полномочия «продавливать» культуру в разработчиков. На деле это складывают на пиэма, а пиэм обычно занят согласованием бабла за выполненные работы и прочей не относящейся к разработке деятельностью.
Насколько я знаю, SAP написан на java, в качестве БД может использовать и oracle, и db2 и вроде бы даже mssql.
На сколько я знаю, в SAP есть какие-то штуки, написанные на Java. А в общем случае так нельзя сказать. Я вообще на вопрос, на чём написан SAP, получил ответ «на ABAP». Наверное, это недалеко от истины. И, кстати, вроде бы есть какой-то форк MySQL специально для SAP и он даже официально поддерживается.
вроде бы есть какой-то форк MySQL специально для SAP и он даже официально поддерживается.
Какие-то ужасы рассказываете. Оно же не поедет. Или вы про MaxDB? Так у MySQL эту игрушку давно отняли.
Верно. Строго говоря, именно продукт SAP ERP (то что называется R/3 или ECC) не содержит java, и полностью написан на ABAP. Есть другие продукты (например, портал, SRM), которые либо полностью работают на java, либо частично.
Есть еще и базовые аспекты. Их сложнее всего победить.
Я говорю о методологиях управления. Существует непреодолимая пропасть между программистами и специалистами управления предприятием или финансистами. Они друг друга не понимают. В результате берутся методологии (технологии) управления или учета десятилетиями вырабатываемые с использованием бумажного носителя информации и в точности копируются программно. Ну типа микроскопом гвозди забиваем.
Именно поэтому иногда использование автоматизированных систем все только усложняют и проекты внедрения проваливаются.
Мы пришли к выводу, что для создания тиражируемых решений автоматизации управления и учета нужно очень внимательно относится к базисным методологиям.
Пример из учета. Счет учета это таблица содержащая поле дебет и поле кредит. Так думает бухгалтер и дает задачу программисту сделать эту табличку в базе данных. Программист делает эту табличку. В действительности в дебете положительные значения, а в кредите отрицательные. На бумаге их разнесли по разным полям, чтобы иметь отдельно сумму по дебету и сумму по кредиту.
Реализуя эту табличку в базе данных нет необходимости иметь два поля, достаточно одно — сумма, а сумму положительный и отрицательных значений по отдельности мы получаем простым запросом. Это маленький пример о том, как влияют методы используемые на бумаге на структуру программы автоматизации. Таких моментов тысячи. Но в результате мы переносим и ограничения возможностей оперирования информацией с бумаги на компьютер. Потом с помощью супер возможностей компьютера пытаемся обойти эти ограничения. Программа получается сложной, настройки мудреными.
Я говорю о методологиях управления. Существует непреодолимая пропасть между программистами и специалистами управления предприятием или финансистами. Они друг друга не понимают. В результате берутся методологии (технологии) управления или учета десятилетиями вырабатываемые с использованием бумажного носителя информации и в точности копируются программно. Ну типа микроскопом гвозди забиваем.
Именно поэтому иногда использование автоматизированных систем все только усложняют и проекты внедрения проваливаются.
Мы пришли к выводу, что для создания тиражируемых решений автоматизации управления и учета нужно очень внимательно относится к базисным методологиям.
Пример из учета. Счет учета это таблица содержащая поле дебет и поле кредит. Так думает бухгалтер и дает задачу программисту сделать эту табличку в базе данных. Программист делает эту табличку. В действительности в дебете положительные значения, а в кредите отрицательные. На бумаге их разнесли по разным полям, чтобы иметь отдельно сумму по дебету и сумму по кредиту.
Реализуя эту табличку в базе данных нет необходимости иметь два поля, достаточно одно — сумма, а сумму положительный и отрицательных значений по отдельности мы получаем простым запросом. Это маленький пример о том, как влияют методы используемые на бумаге на структуру программы автоматизации. Таких моментов тысячи. Но в результате мы переносим и ограничения возможностей оперирования информацией с бумаги на компьютер. Потом с помощью супер возможностей компьютера пытаемся обойти эти ограничения. Программа получается сложной, настройки мудреными.
Не так давно знакомый из крупной компании жаловался: «У нас отличные внутренние продукты, которые разрабатываются нами для нас самих уже второй десяток лет, но пару лет назад пришли ребята и сказали — внедряем [censored], и внедряют его до сих пор, отжирая миллионы каждый месяц». Кратко о причинах внедрения: «…Мы будем продаваться, и это в том числе увеличивает нашу оценочную стоимость».
Вовово, ибо воистину, да будет так. Полностью аналогичная ситуация у одного из наших клиентов.
«Внутренние продукты» очень не впечатляют аудиторов. Когда компания достигает солидной капитализации и хочет хороших инвесторов и больше профита, в том числе и при продаже — внутренние продукты не катят. Да и искать специалистов на их поддержку — то ещё удовольствие, особенно если там какая-нибудь база в FoxPro.
Про индусов есть другая вариация этого анекдота.
Стащили китайцы чертежи нашего новейшего истребителя. Собирают получается паровоз. Снова собирают, опять паровоз. Пришлось выкрасть генконструктора. Привозят. Он смотрит и говорит: «Сколько Вы украли?». Отвечают: «Вагон документации». Он им в ответ: «Ну так надо было еще 10 вагонов изменений украсть».
Соль анекдота заключается не только в том, что в ERP-системах (и подобных им) много дырок. Эти системы настолько сложные, и бизнес-процессы поддерживаемые ими настолько необъятные, что обязательно где-нибудь найдется какая-нибудь дыра в организации поддержки этих самых бизнес-процессов и в организации самих этих бизнес-процессах на предприятии.
Про тиражируемые технологии. С предприятиями какого масштаба Вы работаете? Это чрезвычайно важный момент. Если малые и средние, то никаких проблем действительно не наблюдается при правильном подходе. Если с крупными, то это совсем другой разговор.
Мы работаем с нашими крупными машиностроительными заводами уже более 10 лет (например Сушки, Тушки, Казанские вертолеты и т.п.). И не беремся за ERP, работаем только с PDM, используя очень аккуратно отдельные элементы ERP. Я не знаю как в других странах, а у нас в России есть несколько проблем:
1. Это советское наследство в плохом смысле этого слова. То есть, отсталость, полуразрушенность предприятий, слабая элементная база, косность взглядов, разнесенность предприятий на очень большие территории (несколько городов например).
2. Советское наследство в хорошем смысле этого слова. Собственные наработки в нашей стране по некоторым параметрам превосходят зарубежные или даже современные аналоги. Но они сделаны совершенно на другой концепции и на других стандартах. Очень сложно комбинировать и вливать в мировые стандарты, при этом не теряя ценные наработки.
3. Финансирование во всех смыслах этого слова.
Если взять из аналогов какой-нибудь боинг или аирбас, то там аналогичное положение вещей и индивидуальный подход к разработке.
В качестве еще одного примера могу привести 1С. На сколько мне известно, сейчас они делают активные попытки внедрятся на одном из вертолетных заводов. Лучше бы они этого не делали. На заводе стоят срачики, похлеще сантабарбары. Ну не рассчитано у них работать несколькими сотнями цехов и номенклатурой в пару сотен тысяч изделий в рамках большого завода. Не особо получается пока, хотя я им желаю удачи.
Стащили китайцы чертежи нашего новейшего истребителя. Собирают получается паровоз. Снова собирают, опять паровоз. Пришлось выкрасть генконструктора. Привозят. Он смотрит и говорит: «Сколько Вы украли?». Отвечают: «Вагон документации». Он им в ответ: «Ну так надо было еще 10 вагонов изменений украсть».
Соль анекдота заключается не только в том, что в ERP-системах (и подобных им) много дырок. Эти системы настолько сложные, и бизнес-процессы поддерживаемые ими настолько необъятные, что обязательно где-нибудь найдется какая-нибудь дыра в организации поддержки этих самых бизнес-процессов и в организации самих этих бизнес-процессах на предприятии.
Про тиражируемые технологии. С предприятиями какого масштаба Вы работаете? Это чрезвычайно важный момент. Если малые и средние, то никаких проблем действительно не наблюдается при правильном подходе. Если с крупными, то это совсем другой разговор.
Мы работаем с нашими крупными машиностроительными заводами уже более 10 лет (например Сушки, Тушки, Казанские вертолеты и т.п.). И не беремся за ERP, работаем только с PDM, используя очень аккуратно отдельные элементы ERP. Я не знаю как в других странах, а у нас в России есть несколько проблем:
1. Это советское наследство в плохом смысле этого слова. То есть, отсталость, полуразрушенность предприятий, слабая элементная база, косность взглядов, разнесенность предприятий на очень большие территории (несколько городов например).
2. Советское наследство в хорошем смысле этого слова. Собственные наработки в нашей стране по некоторым параметрам превосходят зарубежные или даже современные аналоги. Но они сделаны совершенно на другой концепции и на других стандартах. Очень сложно комбинировать и вливать в мировые стандарты, при этом не теряя ценные наработки.
3. Финансирование во всех смыслах этого слова.
Если взять из аналогов какой-нибудь боинг или аирбас, то там аналогичное положение вещей и индивидуальный подход к разработке.
В качестве еще одного примера могу привести 1С. На сколько мне известно, сейчас они делают активные попытки внедрятся на одном из вертолетных заводов. Лучше бы они этого не делали. На заводе стоят срачики, похлеще сантабарбары. Ну не рассчитано у них работать несколькими сотнями цехов и номенклатурой в пару сотен тысяч изделий в рамках большого завода. Не особо получается пока, хотя я им желаю удачи.
Тема дыр в безопасности не раскрыта. Заголовок не соответствует содержимому. Разрабатывать не устаревшее ПО для энтерпрайза нереально. От начала до внедрения проекта проходит невероятно большое количество времени. SaaS даже не получится сделать. Хотя тема интересная.
Не понял. Причём тут изменение исходных кодов и «кастомизация»? В нормальных системах можно допиливать функционал путём написания модификаций во внутренней среде разработки, что никак не будет влиять на поддержку и совместимость с выпускаемыми производителем патчами.
Вы бы хотя бы конкретные примеры проблем разобрали что ли, а то и в правду как то неочём.
На Хабре вроде как запрещен кросспостинг: pcmag.ru/columns/detail.php?ID=43993
Прогон какой-то. Непонятно, про какие дыры идёт речь. Сравнение с автопромом неуместно. Автопром делает продукцию, которая устраивает 95% потребителей, допиливают свои тачилы очень небольшой процент. С ERP ситуация совершенно другая.
Вы знакомы с демо-базой Cronus в NAV? Хоть одну компанию встречали, которая работает, используя такую модель бизнес-процессов? Особенно в России — тут вообще п-ц какой-то с организацией рабочих процессов и часто сами заказчики не могут объяснить, как они работают, а на встречах ещё начинают спорить с сами с собой о их же бизнес-процессах.
Говно — оно в головах, а не в системе. В систему оно попадает из голов, и в залежах говнокода виноваты отнюдь не производители. И разгребать в большинстве случаев приходится не код производителя, а код внедренцев, которые писали, как им сказал заказчик.
Вы знакомы с демо-базой Cronus в NAV? Хоть одну компанию встречали, которая работает, используя такую модель бизнес-процессов? Особенно в России — тут вообще п-ц какой-то с организацией рабочих процессов и часто сами заказчики не могут объяснить, как они работают, а на встречах ещё начинают спорить с сами с собой о их же бизнес-процессах.
Говно — оно в головах, а не в системе. В систему оно попадает из голов, и в залежах говнокода виноваты отнюдь не производители. И разгребать в большинстве случаев приходится не код производителя, а код внедренцев, которые писали, как им сказал заказчик.
Автор не имеет представления, о чем пишет.
Про безопасность не скажу — не знаю, но про остальное подписываюсь под каждым словом. У нас SAP Business One. Пару лет его у нас на месте допиливали и в результате получили устаревшее внешне и внутренне необновляемое УГ.
Все данные в формах на сотни полей 8-10 пиксельным шрифтом. В БД таблицы по 300(!) столбцов, а от структуры некоторых волосы на затылке шевелятся. Сервер еле-еле 50 человек держит.
Все данные в формах на сотни полей 8-10 пиксельным шрифтом. В БД таблицы по 300(!) столбцов, а от структуры некоторых волосы на затылке шевелятся. Сервер еле-еле 50 человек держит.
Прочитал тему, честно говоря ничего не понял.
Являюсь консультантом уже 5-й год по внедрению ERP-систем, а именно SAP R/3.
По поводу других систем не скажу, но по поводу SAP свои 5 копеек вставлю.
Какие могут быть дыры:
1) Возможность подключения к системе
2) «Вредительство» пользователей
3) «Вредительство» консультантов/внедренцев
4) Вредительство третьих лиц
А теперь по пунктам.
1) Все вопросы уходят к админам, так как не смогли обеспечить необходимый уровень безопасности системы
2) В данном случае под вредительством понимается криворукость пользователей, в 99.9% случаев ничего серьезного пользователи не смогут натворить, все это исправляется, на что-то серьезное банально не должно быть полномочий
3) после окончания произведенных настроек в системе и передачи в продуктивную эксплуатацию начинается этап сопровождения, как правило у консультантов ограничиваются полномочия на выполнение операций
4) это в принципе довольно затруднительно и обусловлено архитектурой системного ландшафта.
Если кому-то интересно, могу рассказать в рамках своей компетенции.
З.Ы. По своему опыту могу сказать, что к допиливанию приходится прибегать в двух основных случаях:
1) в системе не реализован необходимый функционал
2) Функционал реализован криво или его объема недостаточно
Являюсь консультантом уже 5-й год по внедрению ERP-систем, а именно SAP R/3.
По поводу других систем не скажу, но по поводу SAP свои 5 копеек вставлю.
Какие могут быть дыры:
1) Возможность подключения к системе
2) «Вредительство» пользователей
3) «Вредительство» консультантов/внедренцев
4) Вредительство третьих лиц
А теперь по пунктам.
1) Все вопросы уходят к админам, так как не смогли обеспечить необходимый уровень безопасности системы
2) В данном случае под вредительством понимается криворукость пользователей, в 99.9% случаев ничего серьезного пользователи не смогут натворить, все это исправляется, на что-то серьезное банально не должно быть полномочий
3) после окончания произведенных настроек в системе и передачи в продуктивную эксплуатацию начинается этап сопровождения, как правило у консультантов ограничиваются полномочия на выполнение операций
4) это в принципе довольно затруднительно и обусловлено архитектурой системного ландшафта.
Если кому-то интересно, могу рассказать в рамках своей компетенции.
З.Ы. По своему опыту могу сказать, что к допиливанию приходится прибегать в двух основных случаях:
1) в системе не реализован необходимый функционал
2) Функционал реализован криво или его объема недостаточно
Поддержу Вас.
Честно говоря, не вижу ничего страшного в том что ЕРП-системы дорабатываются и могут дорабатываться. В последнее время SAP реализовал функционал, с помощью которого клиенты могут очень успешно дорабатывать стандартные программы и не бояться при этом стандартных обновлений.
Возможность несанкционированного подключения к системе — это уже полностью решается админами, причем не только SAP-администраторами, а даже больше системными. Все остальное решается полномочиями в системе. Грамотный специалист с верным подходом не оставит пользователю/консультанту ни единого шанса сделать то, что ему не позволено.
Считаю что топик недоработан, если бы вы более предметно показали дыры и рассказали о том как ННреализуется безопасность, то можно было бы предметно обсуждать, а так только вода.
Честно говоря, не вижу ничего страшного в том что ЕРП-системы дорабатываются и могут дорабатываться. В последнее время SAP реализовал функционал, с помощью которого клиенты могут очень успешно дорабатывать стандартные программы и не бояться при этом стандартных обновлений.
Возможность несанкционированного подключения к системе — это уже полностью решается админами, причем не только SAP-администраторами, а даже больше системными. Все остальное решается полномочиями в системе. Грамотный специалист с верным подходом не оставит пользователю/консультанту ни единого шанса сделать то, что ему не позволено.
Считаю что топик недоработан, если бы вы более предметно показали дыры и рассказали о том как ННреализуется безопасность, то можно было бы предметно обсуждать, а так только вода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О «дырах» в безопасности ERP систем