Comments 12
>Нет, ну вот честно, даже смешно. Что так задело беднягу?
Его задело еще не сильно, раз он только письмом ограничился, а вот вас видать сильно зацепило, что даже до хабра докатилось.
Мне вот видится, что врятли зацепило. А вот пиар это да.
У автора приступ болезненной саморекламы через продажу «сферических коней в вакуме». Он один в белом свете AVA ERP(фанфары!!!) — Д`Артаньян а вот всякие «малоизвестные :)» OpenERP, Open Bravo, Compiere и т.д… дальше по контексту.
Много слюней и воды — зато никакой конкретики. Подобную «хрень» часто читаю от «специалистов» критикующих любые другие opensource продукты — причем в тех же словах и выражениях: вот сломается!(у-тю-тю) и никто вам не поможет(так и сдохните под забором :)), а вот купите у нас и мы просто обпомагаемся вам все. Господа — ну вы хоть придумайте что то новое.
п.с:
понимаю что некрокоммент — очень жалею что не заметил пост раньше.
Много слюней и воды — зато никакой конкретики. Подобную «хрень» часто читаю от «специалистов» критикующих любые другие opensource продукты — причем в тех же словах и выражениях: вот сломается!(у-тю-тю) и никто вам не поможет(так и сдохните под забором :)), а вот купите у нас и мы просто обпомагаемся вам все. Господа — ну вы хоть придумайте что то новое.
п.с:
понимаю что некрокоммент — очень жалею что не заметил пост раньше.
На мой взгляд, отсутствие внедрений свободных ERP связано с совершенно другими причинами, и они не технические, на что напирает автор, а организационные.
Дело в том, что любое внедрение — это в первую очередь изменение традиционного уклада существования работников предприятия, и саботаж со стороны, к примеру, бухгалтерии, не просто возможен, он неизбежен. А это означает, что рано или поздно перед руководителем предприятия начнет вставать в полный рост дилемма — разменять пару-тройку «буйных» или прекратить внедрение. В случае доставшейся бесплатно системы решение очевидно — «уж лучше оставить бабу-машу в штате, а то как бы чего не вышло». Ибо отказ от внедрения это как бы «безболезненно» и без видимых денежных потерь (время сотрудников не в счет).
Другое дело, если на внедрение коммерческой системы были потрачены ресурсы, и тут уже совершенно не жалко и бабу машу отправить на пенсию, и вообще кратко и доходчиво объяснить бухгалтерии, кто уже тут хозяин, особенно если внедряется что-то типа SAP, и за консалтинг отданы такие деньги, что лучше уже уволить особо упёртых сотрудников, и нанять на их место помоложе, пошустрее и подешевле, вон сколько зайцев убьём сразу же.
И не надо демонизировать сложность систем управления: там простейшая математика на уровне средней школы + работа с базой данных, так что не важно, свободная система, или вся из себя закрытая.
Важно, чтобы в её внедрение были инвестированы ТАКИЕ деньги, что высшему руководству было не всё равно, окупятся эти инвестиции или нет.
Ничего не имею против бухгалтерии, если что.
Дело в том, что любое внедрение — это в первую очередь изменение традиционного уклада существования работников предприятия, и саботаж со стороны, к примеру, бухгалтерии, не просто возможен, он неизбежен. А это означает, что рано или поздно перед руководителем предприятия начнет вставать в полный рост дилемма — разменять пару-тройку «буйных» или прекратить внедрение. В случае доставшейся бесплатно системы решение очевидно — «уж лучше оставить бабу-машу в штате, а то как бы чего не вышло». Ибо отказ от внедрения это как бы «безболезненно» и без видимых денежных потерь (время сотрудников не в счет).
Другое дело, если на внедрение коммерческой системы были потрачены ресурсы, и тут уже совершенно не жалко и бабу машу отправить на пенсию, и вообще кратко и доходчиво объяснить бухгалтерии, кто уже тут хозяин, особенно если внедряется что-то типа SAP, и за консалтинг отданы такие деньги, что лучше уже уволить особо упёртых сотрудников, и нанять на их место помоложе, пошустрее и подешевле, вон сколько зайцев убьём сразу же.
И не надо демонизировать сложность систем управления: там простейшая математика на уровне средней школы + работа с базой данных, так что не важно, свободная система, или вся из себя закрытая.
Важно, чтобы в её внедрение были инвестированы ТАКИЕ деньги, что высшему руководству было не всё равно, окупятся эти инвестиции или нет.
Ничего не имею против бухгалтерии, если что.
Поддерживаю. При внедрении в больших не-IT компаниях многие решения принимаются по политическим причинам. А если на OpenERP стоит такой слабый игрок (в России), то и результаты будут слабые.
Ну и предвзятость к открытому софту в России, ИМХО, тоже есть.
Так что вопрос качества софта ставится одним из последних (например: зачем покупать качественный софт, если будет хорошая поддержка и наоборот).
Ну и предвзятость к открытому софту в России, ИМХО, тоже есть.
Так что вопрос качества софта ставится одним из последних (например: зачем покупать качественный софт, если будет хорошая поддержка и наоборот).
Похоже тут смешаны 2 разных спора:
1) Открытый/закрытый код базовой системы.
2) Сторонний/внутренний внедренец и сопровождение.
Заголовок обещает нам рассмотрение первого вопроса, но, почему-то, в тексте рассматривается второй.
Первый вопрос должен решать не заказчик, а внедренец и сопровождение (чаще всего это одно лицо). Для заказчика важным может являться только возможность смены сопровождения.
Были бы на российском рынке внедренцы Open Source ERP, было бы из чего выбирать. Если выбор внедренца сделан в пользу внутреннего (IT отдел), то уже этому внутреннему внедренцу выбирать базу на которой строить ERP.
Второй же вопрос гораздо более сложный, чем хочет его представить автор.
В любом случае фирма будет зависима от внедренца и сопровождающего. Сторонняя фирма может содержать лучших специалистов, гибче выделять ресурсы, иметь несравнимо больший опыт. Свой же IT отдел дешевле, гибче управляется, не старается диктовать как надо работать фирме, а реализовывает именно то, что от него требуется. От своего IT отдела можно добиться работоспособного продукта. Если же удалось добиться качественного продукта, то можно выносить IT отдел в дочернюю фирму и оказывать услуги другим (то есть теоретически возможно, но очень сложно).
У меня маленький опыт работы с ERP, но гораздо больший — работы с ДБО (разработка и внедрение). Приходилось видеть и негативные и позитивные результаты всех подходов: и отвратительные доработки своим IT отделом, и застопорившиеся внедрения сторонней фирмой (крупной, с большим штатом разработчиков), и великолепные самописки, и отлично работающие внедренные системы.
Выбор внедренца и сопровождающего — слишком сложный и многогранный вопрос, чтобы на него можно было дать однозначный ответ. И ответ именно на этот вопрос в большей степени определяет успешность проекта, а не открытость/закрытость кода ядра системы.
1) Открытый/закрытый код базовой системы.
2) Сторонний/внутренний внедренец и сопровождение.
Заголовок обещает нам рассмотрение первого вопроса, но, почему-то, в тексте рассматривается второй.
Первый вопрос должен решать не заказчик, а внедренец и сопровождение (чаще всего это одно лицо). Для заказчика важным может являться только возможность смены сопровождения.
Были бы на российском рынке внедренцы Open Source ERP, было бы из чего выбирать. Если выбор внедренца сделан в пользу внутреннего (IT отдел), то уже этому внутреннему внедренцу выбирать базу на которой строить ERP.
Второй же вопрос гораздо более сложный, чем хочет его представить автор.
В любом случае фирма будет зависима от внедренца и сопровождающего. Сторонняя фирма может содержать лучших специалистов, гибче выделять ресурсы, иметь несравнимо больший опыт. Свой же IT отдел дешевле, гибче управляется, не старается диктовать как надо работать фирме, а реализовывает именно то, что от него требуется. От своего IT отдела можно добиться работоспособного продукта. Если же удалось добиться качественного продукта, то можно выносить IT отдел в дочернюю фирму и оказывать услуги другим (то есть теоретически возможно, но очень сложно).
У меня маленький опыт работы с ERP, но гораздо больший — работы с ДБО (разработка и внедрение). Приходилось видеть и негативные и позитивные результаты всех подходов: и отвратительные доработки своим IT отделом, и застопорившиеся внедрения сторонней фирмой (крупной, с большим штатом разработчиков), и великолепные самописки, и отлично работающие внедренные системы.
Выбор внедренца и сопровождающего — слишком сложный и многогранный вопрос, чтобы на него можно было дать однозначный ответ. И ответ именно на этот вопрос в большей степени определяет успешность проекта, а не открытость/закрытость кода ядра системы.
Посмотрел описание и возможности системы на сайте, что-то подумалось про 1С. Ваша система может заменить указанное ПО?
Не поленился, посмотрел ролик из-за которого весь сыр-бор…
Весь ролик сводится к двум постулатам:
— Что если вы сам начнете дорабатывать свою ERP, то через пол года ей придет конец.
— Что программисты в фирме всегда лучше нанятых.
1. Эти утверждение сами по себе бред. Все завист от конкретных людей, которые будут это делать. Или нет примеров когда большие внедряльные конторы обсирались на внедрениях?
2. Автор как пример ненужности исходников приводит телевизор (!!??). Типа при покупке телевизора нам не нужны его принципиальные электрические схемы. Т.е. для автора требования к надежности, а так же сложности замены сломавшегося телевизора и сломавшейся ERP системы находится на одном уровне… что очень хорошо характеризует его как специалиста. А подумаешь что на ERP завязаны миллионы оборота… да заменим в сервисе… за 2-3 месяца )))
3. Дальше автор говорит про 1С. Там он видимо вообще ничего не знает. Он утверждает, что как только вы «влезете» в код, то сразу лишаетесь поддержки 1С. Это тоже ерунда. Обновления вы будете продолжать получать. Другое дело, что обновиться в автоматическом режиме не всегда будет возможно. Но опять же, возможность обновления зависит целиком от того кто вносит изменения. Опять же есть куча примеров когда большие внедряльщики ломают напрочь код…
4. Автор, как и большинство пиарщиков закрытых ERP систем, утверждает, что заказчик не сможет ничего сделать нормально в ERP системе, т.к. это не его бизнес. Но «забывает упомянуть», что везде работают обычные люди. Например в знакомой фирме занимающейся канцелярщиной, и которая по размышлениям автора никогда не сможет сделать ERP, в отделе АСУ работает 14 человек. Есть специалист по бизнес процессам (с профильным образованием), есть программисты и другие необходимые люди. Они успешно работают. В начале они пробовали связываться с фирмами типа вашей. Потратили не один десяток миллионов впустую и теперь набрав людей, сами куют свое счастье. Да, программисты (как и другие работники) периодически меняются. Но разработка от этого не встает и никто не кричит караул. И приходящие нормально разбираются в том, что написано. В общем автор опять ерунду сморозил… Он просто не понимает, что ERP меряется не количеством бабла отдаваемых внедряльщику… что есть такое понятие как риски. Что многие готовы доплатить, чтобы получить независимость от внедряльщика и уменьшить вероятность упереться в стенку.
Во всех его постах и в этом ролике, автор постоянно передергивает факты в свою пользу. При чем в ролике очень часто проскакивают фразы типа «возьмете опенсорс, что-то случиться и у вас все будет плохо»… и постоянно что-то должно случиться, что именно случится автор не знает… но оно обязательно порушит все ))
ИМХО. В общем автор очередной раз доказал что он клоун пиарщик, который мало что понимает в том. о чем говорит…
Весь ролик сводится к двум постулатам:
— Что если вы сам начнете дорабатывать свою ERP, то через пол года ей придет конец.
— Что программисты в фирме всегда лучше нанятых.
1. Эти утверждение сами по себе бред. Все завист от конкретных людей, которые будут это делать. Или нет примеров когда большие внедряльные конторы обсирались на внедрениях?
2. Автор как пример ненужности исходников приводит телевизор (!!??). Типа при покупке телевизора нам не нужны его принципиальные электрические схемы. Т.е. для автора требования к надежности, а так же сложности замены сломавшегося телевизора и сломавшейся ERP системы находится на одном уровне… что очень хорошо характеризует его как специалиста. А подумаешь что на ERP завязаны миллионы оборота… да заменим в сервисе… за 2-3 месяца )))
3. Дальше автор говорит про 1С. Там он видимо вообще ничего не знает. Он утверждает, что как только вы «влезете» в код, то сразу лишаетесь поддержки 1С. Это тоже ерунда. Обновления вы будете продолжать получать. Другое дело, что обновиться в автоматическом режиме не всегда будет возможно. Но опять же, возможность обновления зависит целиком от того кто вносит изменения. Опять же есть куча примеров когда большие внедряльщики ломают напрочь код…
4. Автор, как и большинство пиарщиков закрытых ERP систем, утверждает, что заказчик не сможет ничего сделать нормально в ERP системе, т.к. это не его бизнес. Но «забывает упомянуть», что везде работают обычные люди. Например в знакомой фирме занимающейся канцелярщиной, и которая по размышлениям автора никогда не сможет сделать ERP, в отделе АСУ работает 14 человек. Есть специалист по бизнес процессам (с профильным образованием), есть программисты и другие необходимые люди. Они успешно работают. В начале они пробовали связываться с фирмами типа вашей. Потратили не один десяток миллионов впустую и теперь набрав людей, сами куют свое счастье. Да, программисты (как и другие работники) периодически меняются. Но разработка от этого не встает и никто не кричит караул. И приходящие нормально разбираются в том, что написано. В общем автор опять ерунду сморозил… Он просто не понимает, что ERP меряется не количеством бабла отдаваемых внедряльщику… что есть такое понятие как риски. Что многие готовы доплатить, чтобы получить независимость от внедряльщика и уменьшить вероятность упереться в стенку.
Во всех его постах и в этом ролике, автор постоянно передергивает факты в свою пользу. При чем в ролике очень часто проскакивают фразы типа «возьмете опенсорс, что-то случиться и у вас все будет плохо»… и постоянно что-то должно случиться, что именно случится автор не знает… но оно обязательно порушит все ))
ИМХО. В общем автор очередной раз доказал что он клоун пиарщик, который мало что понимает в том. о чем говорит…
Решил посмотреть ролики. Жалею о потерянном времени. Занимательный на первый взгляд материал оказался маркетинговой пустышкой.
От простого передергивания и ложных аналогий до откровенной дезинформации.
Начнем с ложной аналогии про телевизор, к которому схема не нужна так как ковыряться паяльником в нем ни кто не будет.
Эта аналогия ложна по целому ряду причин среди которых и важность поломки, и невозможность ждать ремонта, и невозможность легко заменить и необходимость постоянных изменений под изменяющиеся бизнеспроцессы. Но есть и верные аспекты: схема к телевизору нужна телемастеру, который будет его чинить. И если не устроит телемастер от производителя, то сторонний сделает дешевле.
В конце концов исходники нужны не только для изменений, но и для аудита безопасности системы. Даже если их запрещено менять их показывают, чтобы заказчик мог их проверить.
«Приоткрытые исходные коды» — это разделение системы на ядро и бизнеслогику (ядро закрыто, бизнеслогика открыта, возможно без права изменений). Подобное разделение позволяет создавать огромное количество конфигураций с одном ядром. Ядро удается отладить до состояния близкого к идеалу, а бизнеслогику сделать предельно гибкой. Если такого разделения нет, то это огромный минус системы — у 10 заказчиков будут стоять не 10 конфигураций одной системы, а 10 разных систем. И править одни и те же баги ядра придется в 10 системах, что сказывается на стоимости.
Если у вас нет обособленного ядра, то не удивительно, что вы не открываете коды бизнеслогики — вы их просто не можете открыть, не открыв все. Вы можете свой недостаток выдавать за достоинство на презентациях, но зачем это пытаться делать на сайте, где множество людей знают эту тему на практике?
Про отсутствие поддержки со стороны производителя тоже глупость. Опус про недоступность обновлений после самостоятельных изменений я специально дал послушать человеку, который является штатным 1С разработчиком в крупной фирме. Наградой мне было крайне удивленное выражение лица. Для обновления 1С в крупном предприятии требуется 2 часа работы одного программиста. Естественно все изменения делались с оглядкой на то, что их придется поддерживать, но так и должно быть в нормальном IT отделе.
Вообще довольно странно было бы для правки в отчете которую штатный программист в 1С может внести за час, а бухгалтерии она нужна вчера ждать 16 часов и это только на консультацию (кажется такие цифры у вас на сайте).
Про коллапс продукта через полгода самостоятельной разработки тоже жуткое передергивание. Разработчики вашей фирмы не боги, собственные разработчики заказчика тоже не обязательно из дурдома набраны. Хочет заказчик сам поддерживать систему — пусть сколачивает себе хороший IT отдел с соответствующими зарплатами. Банки, например, в свой IT отдел любят разработчиков ДБО переманивать.
Про отсутствие пути назад после самостоятельных изменений — все зависит от ваших возможностей и денег заказчика. Я участвовал в успешном принятии на поддержку функционала наработанного за полтора года крайне низко квалифицированными разработчиками. Долго, дорого, но возможно. Если вы такого не делаете — это исключительно ваш минус.
Всё. 3 минуты от первого ролика. Текст я бы еще осилил, но медленная речь в которой каждое предложение вызывает негодование просто невыносима.
Дальше шли куски про то, что единственный (это почему?) внутренний разработчик уволится и можно ползти на кладбище. Вот только опять же 1С разработчик, которому я все это показывал, оказалось несколько лет назад сам принимал чужие многолетние наработки и фирма пока цела.
А вот что делать, если вы разоритесь или цены за техподдержку увеличите до неприличия? В 1С, САП и других можно просто сменить сопровождающую систему фирму или перейти на собственное сопровождение, а ваши клиенты в западне.
От простого передергивания и ложных аналогий до откровенной дезинформации.
Начнем с ложной аналогии про телевизор, к которому схема не нужна так как ковыряться паяльником в нем ни кто не будет.
Эта аналогия ложна по целому ряду причин среди которых и важность поломки, и невозможность ждать ремонта, и невозможность легко заменить и необходимость постоянных изменений под изменяющиеся бизнеспроцессы. Но есть и верные аспекты: схема к телевизору нужна телемастеру, который будет его чинить. И если не устроит телемастер от производителя, то сторонний сделает дешевле.
В конце концов исходники нужны не только для изменений, но и для аудита безопасности системы. Даже если их запрещено менять их показывают, чтобы заказчик мог их проверить.
«Приоткрытые исходные коды» — это разделение системы на ядро и бизнеслогику (ядро закрыто, бизнеслогика открыта, возможно без права изменений). Подобное разделение позволяет создавать огромное количество конфигураций с одном ядром. Ядро удается отладить до состояния близкого к идеалу, а бизнеслогику сделать предельно гибкой. Если такого разделения нет, то это огромный минус системы — у 10 заказчиков будут стоять не 10 конфигураций одной системы, а 10 разных систем. И править одни и те же баги ядра придется в 10 системах, что сказывается на стоимости.
Если у вас нет обособленного ядра, то не удивительно, что вы не открываете коды бизнеслогики — вы их просто не можете открыть, не открыв все. Вы можете свой недостаток выдавать за достоинство на презентациях, но зачем это пытаться делать на сайте, где множество людей знают эту тему на практике?
Про отсутствие поддержки со стороны производителя тоже глупость. Опус про недоступность обновлений после самостоятельных изменений я специально дал послушать человеку, который является штатным 1С разработчиком в крупной фирме. Наградой мне было крайне удивленное выражение лица. Для обновления 1С в крупном предприятии требуется 2 часа работы одного программиста. Естественно все изменения делались с оглядкой на то, что их придется поддерживать, но так и должно быть в нормальном IT отделе.
Вообще довольно странно было бы для правки в отчете которую штатный программист в 1С может внести за час, а бухгалтерии она нужна вчера ждать 16 часов и это только на консультацию (кажется такие цифры у вас на сайте).
Про коллапс продукта через полгода самостоятельной разработки тоже жуткое передергивание. Разработчики вашей фирмы не боги, собственные разработчики заказчика тоже не обязательно из дурдома набраны. Хочет заказчик сам поддерживать систему — пусть сколачивает себе хороший IT отдел с соответствующими зарплатами. Банки, например, в свой IT отдел любят разработчиков ДБО переманивать.
Про отсутствие пути назад после самостоятельных изменений — все зависит от ваших возможностей и денег заказчика. Я участвовал в успешном принятии на поддержку функционала наработанного за полтора года крайне низко квалифицированными разработчиками. Долго, дорого, но возможно. Если вы такого не делаете — это исключительно ваш минус.
Всё. 3 минуты от первого ролика. Текст я бы еще осилил, но медленная речь в которой каждое предложение вызывает негодование просто невыносима.
Дальше шли куски про то, что единственный (это почему?) внутренний разработчик уволится и можно ползти на кладбище. Вот только опять же 1С разработчик, которому я все это показывал, оказалось несколько лет назад сам принимал чужие многолетние наработки и фирма пока цела.
А вот что делать, если вы разоритесь или цены за техподдержку увеличите до неприличия? В 1С, САП и других можно просто сменить сопровождающую систему фирму или перейти на собственное сопровождение, а ваши клиенты в западне.
Если уж брать аналогию со схемой телевизора, то наличие этой схемы не является показателем качества изделия. Это просто дополнительный плюс, возможность самостоятельно внести изменения (хорошие или плохие — зависит от мастера).
По поводу уволившихся программистов. Работаю компании где в 1989 году написали систему учета заявок на DOS. Программисты уволились в 1991 году. Работает до сих пор. А год сейчас уже 2015. Бизнес процессы не менялись лет 50 уже. Исходного кода нет. Работает программа через подключенный сетевой диск, exe файл запускаешь и все.
Sign up to leave a comment.
Любителям open source ERP систем посвящается