Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 140
Изначально не те люди стали заниматься управлением компанией — им это не дано, если только через 10 лет поняли свои ошибки.
Очень многие никогда не поймут своей ошибки, а еще больше никогда ее не признают и даже не попытаются найти решение.
Так что эти «люди» вполне сносные
Так что эти «люди» вполне сносные
Если компания существует уже 10 лет, то ваш тезис спорен.
10 лет все одно: продаем, развиваемся, недоверяем левым людям, когда они не могут убедить, что пора ПО менять.
Зануды одним словом.
Зануды одним словом.
думаю нужно плясать от бизнес-процессов. не важно на какой платформе.
цитата:
— Иными словами все вопросы, от момента получения заказа до момент вручения груза клиенту, решены весьма и весьма неплохо.
…
Но если десять лет назад именно эти проблемы и стояли во главе угла, то сейчас, когда в компании трудится 150 сотрудников, главная проблема — совсем не логистика и не склад.
— — за десять лет поменялись задачи, значит надо либо расширять либо менять. Если б десять лет назад сразу купили и внедрили более широкую (в смысле задач) ERP то сейчас такой вопрос не стоял бы. А может и ещё хуже б было, количество провалов у внедряльщиков 50% по статистике.
Такое впечатление всегда создаётся когда на новое место приходишь, это нормально. Пример:
можно лечить зубы в одной больнице. потом прийти в другую и новый доктор сразу начнёт ругать предидущего. И пломбы неправильные, и каналы не почищены, и коронку надо было сразу ставить ещё в прошлом году.
— Иными словами все вопросы, от момента получения заказа до момент вручения груза клиенту, решены весьма и весьма неплохо.
…
Но если десять лет назад именно эти проблемы и стояли во главе угла, то сейчас, когда в компании трудится 150 сотрудников, главная проблема — совсем не логистика и не склад.
— — за десять лет поменялись задачи, значит надо либо расширять либо менять. Если б десять лет назад сразу купили и внедрили более широкую (в смысле задач) ERP то сейчас такой вопрос не стоял бы. А может и ещё хуже б было, количество провалов у внедряльщиков 50% по статистике.
Такое впечатление всегда создаётся когда на новое место приходишь, это нормально. Пример:
можно лечить зубы в одной больнице. потом прийти в другую и новый доктор сразу начнёт ругать предидущего. И пломбы неправильные, и каналы не почищены, и коронку надо было сразу ставить ещё в прошлом году.
цитата:
за десять лет поменялись задачи, значит надо либо расширять либо менять. Если б десять лет назад сразу купили и внедрили более широкую (в смысле задач) ERP то сейчас такой вопрос не стоял бы. А может и ещё хуже б было, количество провалов у внедряльщиков 50% по статистике.
Такое впечатление всегда создаётся когда на новое место приходишь, это нормально. Пример:
можно лечить зубы в одной больнице. потом прийти в другую и новый доктор сразу начнёт ругать предидущего. И пломбы неправильные, и каналы не почищены, и коронку надо было сразу ставить ещё в прошлом году.
Иными словами все вопросы, от момента получения заказа до момент вручения груза клиенту, решены весьма и весьма неплохо.
…
Но если десять лет назад именно эти проблемы и стояли во главе угла, то сейчас, когда в компании трудится 150 сотрудников, главная проблема — совсем не логистика и не склад.
за десять лет поменялись задачи, значит надо либо расширять либо менять. Если б десять лет назад сразу купили и внедрили более широкую (в смысле задач) ERP то сейчас такой вопрос не стоял бы. А может и ещё хуже б было, количество провалов у внедряльщиков 50% по статистике.
Такое впечатление всегда создаётся когда на новое место приходишь, это нормально. Пример:
можно лечить зубы в одной больнице. потом прийти в другую и новый доктор сразу начнёт ругать предидущего. И пломбы неправильные, и каналы не почищены, и коронку надо было сразу ставить ещё в прошлом году.
Про отечественные ERP-системы: skif-by.livejournal.com/91954.html
Господа, а насколько хороша Apache Ofbiz, как ERP система?
Единственный выход в этой ситуации — покупать еще один продукт
Единственный разумный выход — это пригласить независимого ИТ-аудитора, квалифицированного в программной архитектуре, чтобы он дал объективную оценку разработанной за 10 лет системе… точнее единственному модулю системы. Если он скажет, что средняя оценка — человеко-год, то с высокой степенью вероятности нынешний ИТ-департамент этой конторы будет 20 лет внедрять новый продукт и еще 30 лет его интегрировать с существующим.
А то решение, которое предлагаете Вы — достаточно типичное для продавцов ERP. Я могу написать десятки постов-примеров, когда внедрение растягивалось на годы с последующей отправкой ERP в помойку.
Единственный разумный выход — это пригласить независимого ИТ-аудитора, квалифицированного в программной архитектуре, чтобы он дал объективную оценку разработанной за 10 лет системе… точнее единственному модулю системы. Если он скажет, что средняя оценка — человеко-год, то с высокой степенью вероятности нынешний ИТ-департамент этой конторы будет 20 лет внедрять новый продукт и еще 30 лет его интегрировать с существующим.
А то решение, которое предлагаете Вы — достаточно типичное для продавцов ERP. Я могу написать десятки постов-примеров, когда внедрение растягивалось на годы с последующей отправкой ERP в помойку.
Я подобную ситуацию уже решал. Мне досталась самописная, корявая но вполне рабочая CRM. Сразу перескочить на полноценную ERP нереально, поскольку бизнес-процессы и данные первичных документов сильно не совпадают. Например, использовалось всего три документа — заказ, резерв, поступление, списание. Причем, заказ был очень сильно развит и перегружен всякой спецификой, резервом оформлялось отправка материалов на производство и поступление готовых изделий на склад, а списание было и отгрузкой, и складским перемещением. На самом деле все было еще сложнее, поскольку отгрузку можно было оформить любым из этих документов. Жесть. Но как-то работает.
Я просто начал плавно приводить функционал в соответствие с общепринятым. Убрал из заказа все лишнее и неиспользуемое, а также возможность влиять на остаток. Но при этом в заказе динамически отображается состояние оплаты, резерва и наличия. Сделал реализацию отдельной операцией. Сделал резерв именно резервом, а не списанием. Сделал примитивный, но эффективный учет движения финансов. То есть, плавно подогнал под общие стандарты. Теперь можно без особых сложностей перегнать данные в любую ERP, но пока такой надобности не возникает. =)
Я просто начал плавно приводить функционал в соответствие с общепринятым. Убрал из заказа все лишнее и неиспользуемое, а также возможность влиять на остаток. Но при этом в заказе динамически отображается состояние оплаты, резерва и наличия. Сделал реализацию отдельной операцией. Сделал резерв именно резервом, а не списанием. Сделал примитивный, но эффективный учет движения финансов. То есть, плавно подогнал под общие стандарты. Теперь можно без особых сложностей перегнать данные в любую ERP, но пока такой надобности не возникает. =)
>>> Да, есть какие-то финансовые отчеты, которые кто-то делает руками в excel. Но их правдивость сомнительна, качество низкое, проверить цифры нельзя, да и запаздывает отчетность очень прилично.
Кому-то в компании-заказчике это выгодно. В мутной водичке хорошо рыбку ловить.
Кому-то в компании-заказчике это выгодно. В мутной водичке хорошо рыбку ловить.
А в чем проблема допилить существующий продукт? Может в том, что сами руководители не знают, что именно нужно? Я не могу поверить, что куча программистов на уже существующей системе не сможет реализовать отчет, который сейчас «делается в Экселе руками». Очень часть ERP-системы воспринимаются как некая панацея от всех проблем. Мол, стоит только внедрить — а дальше все само собой наладится. Нет. Начинать нужно не с внедрения системы, а с понимания цели. Поймут цели, смогут их внятно сформулировать — дальше дело техники на уже существующей системе доделать нужный функционал.
ERP системы не воспринимаются людьми как панацея сами по себе… это мнение им навязывают пиарщики ERP систем, убеждая и убедительно аргументируя разными сложными понятиями… по сути манипулируя людьми…
В систему не заносятся все данные, генерируемые бизнесом — там же только лгистика. Поэтому и отчеты построить нельзя.
Ах данные не заносятся… А в ERP-системе данные откуда возьмутся? С неба упадут по мановению волшебной палочки? Или придется сотрудников своих напрягать? В таком случае что мешает в уже существующей, своей родной, привычной, и, самое главное, индивидуальной, заточенной именно под этот бизнес системе, добавить функционал?
Ну, ну, что ж Вы так эмоционально? И я вообще не понимаю почему руководителям любят приписывать поведение детей. Даже при российском уровне раздолбайства по моему опыту когда не делается что-то очевидное, то это имеет несколько более сложные причины, чем нежелание сделать имеено это. Проще говоря, часто какая-то одна нужна активность генерирует кучу контрактивностей в другом месте, и талант менеджера находить баланс. Касательно обсуждаемого — автор же написал, что там только логистика и склад. И что за 10 лет не удалось добавить аналоги всех остальных компонент больших систем, что запутались сами развивать систему. Такое случается, часто. Так что если и говорить про волшебную палочку, то именно автоматизация непокрытых кусков бизнеса требуют больших инвестиций, часто слишком дорогих для небольших компаний. Или волшебную палочку.
А представьте, себе современный смартфон. Умеет дохрена всего всякого, но используется в основном для звонков. Даже банальный голосовой набор не используется, хотя он бывает удобен и мог бы сэкономить время.
Так вот, кто-то изучает смартфон досконально, тратит время на настройку, кастомизацию, перенос контактов, заметок, установку и обновление приложений. А кто-то использует отдельно телефон и отдельно бумажный блокнотик. Оба вполне довольны.
Так вот, кто-то изучает смартфон досконально, тратит время на настройку, кастомизацию, перенос контактов, заметок, установку и обновление приложений. А кто-то использует отдельно телефон и отдельно бумажный блокнотик. Оба вполне довольны.
Не бойтесь того, что люди прикипели.
Четверть перестроится ибо продвинутая молодежь,
еще четверть по принуждению, ибо предпенсионный возраст и рыпаться некуда, только терпеть,
еще четверть престроится, так как их роль не зависит от платформы и реализации, бей штрих-сканером строчки в документе и не парься,
остальным придется трудно и нудно перестраиваться только потому что их уже меньшинство.
Единицы уйдут. Найдется замена.
Просто я считал, что нашу организацию не возможно сдвинуть с насиженного места в нашей ЕРПе. Ничего перешли. Да Очень сложно, да нужна абсолютная инициатива не только внедренцев но и ген. дира и всех начальников и отдельных личностей на местах. Сложно но можно.
Удачи в любом случае.
Четверть перестроится ибо продвинутая молодежь,
еще четверть по принуждению, ибо предпенсионный возраст и рыпаться некуда, только терпеть,
еще четверть престроится, так как их роль не зависит от платформы и реализации, бей штрих-сканером строчки в документе и не парься,
остальным придется трудно и нудно перестраиваться только потому что их уже меньшинство.
Единицы уйдут. Найдется замена.
Просто я считал, что нашу организацию не возможно сдвинуть с насиженного места в нашей ЕРПе. Ничего перешли. Да Очень сложно, да нужна абсолютная инициатива не только внедренцев но и ген. дира и всех начальников и отдельных личностей на местах. Сложно но можно.
Удачи в любом случае.
Вот любят эти пиарщики ERP систем, писать желтые статьи…
Коротко статья:
Кто-то где-то разрабатывал сам ERP. Что-то у него получилось, что-то нет. И хоть мы толком ничего посоветовать не можем, но все равно это плохо — потому как собственная разработка по определению плохая.
(В статье подразумевается, что собственные разработки отбирают у них бабло и они везде где тлько могут пишут, что это невероятно сложно писать свою систему, лучше покупать готовую)
Мой личный опыт разработки и внедрения ERP на различных предприятиях говорит об обратном.
Производители ERP систем гребут бабло лопатами, требуя за каждый чих немерянные деньги, при этом приходится бизнес «натягивать» на логику программы, а не программу менять под процессы бизнеса. Ошибки не исправляются годами, или исправляются опять с ошибками, на многие запросы ответ один «невозможно» и т.д. и т.п.
Многие начинают разрабатывать свою ERP после попыток получить от готовых решений толк. Но ведь все разработчики ERP почему-то считают, что только они гениальные методисты. Только они знают как надо рулить бизнесом. И в результате бедные клиенты ломают свои бизнес процессы на «оптимальные»… с чего вы вообще взяли, что лучше знаете как рулить бизнесом чем люди которые варятся в этом многие годы?
Я просто ненавижу консультантов ERP систем которые несут всякую ересь, убеждая руководство в немерянной сложности ПО и необходимости все в организации поменять, чтобы их гениальные бизнес процессы показали всю свою мощь!
Говорите отчетов не было нужных? И вывод делаете, что разработчики просто так 10 лет чего-то писали? Так может им не ставили задачу по этому отчету? А может все дело в том, вам лучше свою ERP с поддержкой продать — чем написать отчет или поставить задачу разработчикам по его написанию?
10 лет вообще ни о чем не говорит… во всех известных мне конторах доработка ПО идет постоянно, никогда не остановится и немного отстает от запросов бизнеса, но ведь это не повод впаривать им новую систему…
P.S. Извините. Наболело…
Коротко статья:
Кто-то где-то разрабатывал сам ERP. Что-то у него получилось, что-то нет. И хоть мы толком ничего посоветовать не можем, но все равно это плохо — потому как собственная разработка по определению плохая.
(В статье подразумевается, что собственные разработки отбирают у них бабло и они везде где тлько могут пишут, что это невероятно сложно писать свою систему, лучше покупать готовую)
Мой личный опыт разработки и внедрения ERP на различных предприятиях говорит об обратном.
Производители ERP систем гребут бабло лопатами, требуя за каждый чих немерянные деньги, при этом приходится бизнес «натягивать» на логику программы, а не программу менять под процессы бизнеса. Ошибки не исправляются годами, или исправляются опять с ошибками, на многие запросы ответ один «невозможно» и т.д. и т.п.
Многие начинают разрабатывать свою ERP после попыток получить от готовых решений толк. Но ведь все разработчики ERP почему-то считают, что только они гениальные методисты. Только они знают как надо рулить бизнесом. И в результате бедные клиенты ломают свои бизнес процессы на «оптимальные»… с чего вы вообще взяли, что лучше знаете как рулить бизнесом чем люди которые варятся в этом многие годы?
Я просто ненавижу консультантов ERP систем которые несут всякую ересь, убеждая руководство в немерянной сложности ПО и необходимости все в организации поменять, чтобы их гениальные бизнес процессы показали всю свою мощь!
Говорите отчетов не было нужных? И вывод делаете, что разработчики просто так 10 лет чего-то писали? Так может им не ставили задачу по этому отчету? А может все дело в том, вам лучше свою ERP с поддержкой продать — чем написать отчет или поставить задачу разработчикам по его написанию?
10 лет вообще ни о чем не говорит… во всех известных мне конторах доработка ПО идет постоянно, никогда не остановится и немного отстает от запросов бизнеса, но ведь это не повод впаривать им новую систему…
P.S. Извините. Наболело…
Кстати да, у нас так же начали внедрять крутую ОдинЭс только потому, что новый начальник АСУ не знает «Галактику». И пофиг, что всё обкатано, отточено и удовлетворяет большинство задач. А стоило бы только купить модуль разработчика, чтобы можно было дописывать самому хотелки(их не так и много было на самом деле). Нет же) Переучили 160 пользователей на 1С, переучили(читай заставили изучать в очень сжатые сроки) штатных программистов на 1С, посадили на Кривую «УСО», которая обновляется вообще в самую последнюю очередь. Плюсои не самых лучших внедренцев выбрали(если не самых худших ИМХО)
Да плюсы видны после перехода… Но блин какой ценой.
Да плюсы видны после перехода… Но блин какой ценой.
… при этом приходится бизнес «натягивать» на логику программы, а не программу менять под процессы бизнеса.
Золотые слова! Именно по этой причине мы пилим 2-й год свою систему, которая развивается вместе с бизнесом, и, что важнее, бизнес развивается вместе с ней. Прикидывая калькуляцию стоимости изменений в какой-нибудь ERP за это время (не считая первоначальной разработки), я понимаю что бизнесу пришлось бы работать исключительно на доработку этой системы. А ведь помимо внутренних бизнес-процессов, есть еще внешние факторы (законы, налоги, поставщики со своими системами...)
P.S. Извините, тоже очень болезненный мозоль…
Очередная песня покупайте наших слонов у нас все хорошо. Только вот потом выясняется, что ухода от анализа что и как делается в компании, а так же от настройки бизнес-процессов и дописывания функционала в рамках ERP никуда не деться. Только вот это все может выливаться в крупные суммы денег и меньшую скорость разработки. Так что в любом случае прежде чем покупать ERP как уже и говорилось нужен анализ ситуации.
покупные ERP очень сильно страдают косностью и неповоротливостью. Как правильно заметил предыдущий оратор, не система подстраивается под бизнес, а бизнес под систему. И чаще всего это плохо для будущего этого бизнеса, потому что просто так вы уже свои бизнес-процессы не перестроите и не оптимизируете — крутая ERP вам этого не позволит (если, конечно, вы не заплатите за новый аудит процессов, доработку конфигурации, внедрение новой версии и т.п.). Бизнес после такого внедрения замирает на месте. Всё вокруг меняется, а он застыл в одном времени. Только вот конкуренты почему-то бегут вперёд.
«Всем им кажется, что все в их продукте чертовски удобно». Не может сотрудникам этого казаться. Либо оно удобно, либо нет. А удобно оно им потому, что все эти грёбаные 10 лет именно они (кладовщики, манагеры, снабженцы) ставили задачи разработчикам. Система росла снизу, как же ей решать задачи руководства, если оно 10 лет удовлетворялось эксельками раз в месяц? Не поможет руководству этой конторы и покупная ERP — ну не придумали ещё универсальных систем с одной кнопкой «сделать заебись». Тут подход к управлению компанией надо менять.
«Всем им кажется, что все в их продукте чертовски удобно». Не может сотрудникам этого казаться. Либо оно удобно, либо нет. А удобно оно им потому, что все эти грёбаные 10 лет именно они (кладовщики, манагеры, снабженцы) ставили задачи разработчикам. Система росла снизу, как же ей решать задачи руководства, если оно 10 лет удовлетворялось эксельками раз в месяц? Не поможет руководству этой конторы и покупная ERP — ну не придумали ещё универсальных систем с одной кнопкой «сделать заебись». Тут подход к управлению компанией надо менять.
Косностью и неповоротливостью страдают не ERP системы. Поверьте, ни ERP ни любой другой класс систем — вообще не страдают. Они так сказать лишены чувств.
Страдают, причем совсем не этим, люди которые их внедряют.
Страдают, причем совсем не этим, люди которые их внедряют.
Ну что вы, милейший. Никакого отношения к ERP представленная информация не имеет. Важны люди которые её делают, а платформа это только коэффициент трудозатрат.
Заоупенсорсить систему, пропиарить, подключить к работе коммьюнити и за пару лет сделать более-менее качественный продукт.
Увольняйтесь.
Подобные системы разрабатываются под текущие нужды и зачастую ни разработчик, ни сам заказчик не знаю, а что там будет через полгода. Навесили одну фичу, потом навесили еще. В итоге получился пускай и работающий, но страшный косоглазый беззубый монстр.
Скорее всего, когда это начиналось, никто и не думал называть программу ERP.
Была нужна какая-то отчетность — ок, ее сделали. Потом еще отчет, и еще, и еще. Проверка отчетов? Боже, увольте! Деньги пришли — деньги ушли, сходили в кабак — и хорошо.
И почему вы говорите, что единственный выход — приделать еще один костыль в виде стороннего продукта?
Обычно когда подобные компании подходят к такому барьеру, то варианта 2: или пересматривать бизнес-процессы и проводить реинженеринг с внедрением нового продукта, или, простите, тихо умереть.
Скорее всего, когда это начиналось, никто и не думал называть программу ERP.
Была нужна какая-то отчетность — ок, ее сделали. Потом еще отчет, и еще, и еще. Проверка отчетов? Боже, увольте! Деньги пришли — деньги ушли, сходили в кабак — и хорошо.
И почему вы говорите, что единственный выход — приделать еще один костыль в виде стороннего продукта?
Обычно когда подобные компании подходят к такому барьеру, то варианта 2: или пересматривать бизнес-процессы и проводить реинженеринг с внедрением нового продукта, или, простите, тихо умереть.
Вполне нормальная и обычная ситуация описана. Для (совковых?) компаний, где ИТ не считают важной системой поддержки бизнеса, есть пара программистов-середнячков и ИТ-директор, в основном занимающийся закупкой новой оргтехники.
Надо просто усилить блок ИТ. Нанять хороших программеров за хорошие деньги, толковых бизнес-аналитиков и обязательно человека, который будет целиком и полностью отвечать за корпоративную модель данных (то, над чем в первую очередь трястись надо, а не над программами-интерфейсами к КМД) — грамотные справочники НСИ, онтология бизнес-объектов (жизненный цикл), чтобы все подробно описано было, регулярный аудит данных и т.д.
Пидарасы-интеграторы сначала слупят дохрена, работающий и гибкий продукт не получит бизнес, поддержка либо fuckupовская, либо опять же за большие бабосы. В итоге выйдет дешевле и лучше самим уж делать все под себя. Руководители почему-то думают, что если большие деньги платят интегратору, то проблемы решены. А проблемы только начнутся у компании…
Надо просто усилить блок ИТ. Нанять хороших программеров за хорошие деньги, толковых бизнес-аналитиков и обязательно человека, который будет целиком и полностью отвечать за корпоративную модель данных (то, над чем в первую очередь трястись надо, а не над программами-интерфейсами к КМД) — грамотные справочники НСИ, онтология бизнес-объектов (жизненный цикл), чтобы все подробно описано было, регулярный аудит данных и т.д.
Пидарасы-интеграторы сначала слупят дохрена, работающий и гибкий продукт не получит бизнес, поддержка либо fuckupовская, либо опять же за большие бабосы. В итоге выйдет дешевле и лучше самим уж делать все под себя. Руководители почему-то думают, что если большие деньги платят интегратору, то проблемы решены. А проблемы только начнутся у компании…
Многие коробочные продукты выросли из внутренних систем. Тот же nginx. А писаные с нуля для продажи системы порой напоминают эдакий blowjob tournament — как бы побольше потенциальных клиентов удовлетворить. Битрикс, например.
Кроме того, часто встречается обратная ситуация. Стоит внедрение, а бизнес из него вырос. Штатными средствами не расширяется, перейти резко на новое нельзя по тем же причинам, что озвучены в статье, а свое писать (теперь уже) слишком поздно. Надо было раньше.
Кроме того, часто встречается обратная ситуация. Стоит внедрение, а бизнес из него вырос. Штатными средствами не расширяется, перейти резко на новое нельзя по тем же причинам, что озвучены в статье, а свое писать (теперь уже) слишком поздно. Надо было раньше.
Почему не получится разработать новую своими силами?
Я был в такой ситуации, и пришел работать именно в такую компанию (прям читал и плакал).
До меня написали страшную версию 1.0 (силами гендира на технологиях начала 90-х), меня взяли её менять, за 5 лет компания выросла почти в 10 раз, появились новые направления и штат вырос.
Ничего, создал отдел автоматизации с нуля.
Писал сам, набирал команду, и писали-анализировали-ковыряли-оптимизировали, при этом, старая система должна была не только поддерживаться, но развиваться в систему версии 1.5, которая работала совместно с новой системой версии 1.0, которая в свою очередь в версии 2.0 должа была заменить их обеих.
Получилось замечательно, компания получала в каждый нужный момент времени ту версию — которая была ей необходима, при этом проектирование принципиально новой системы не останавливалось ни на шаг.
Были конечно сложности с появлением одновременнно двух инструментариев — но все это решаемо, главное подобрать команду в которой решались вопросы проектирования и архитектуры.
Я был в такой ситуации, и пришел работать именно в такую компанию (прям читал и плакал).
До меня написали страшную версию 1.0 (силами гендира на технологиях начала 90-х), меня взяли её менять, за 5 лет компания выросла почти в 10 раз, появились новые направления и штат вырос.
Ничего, создал отдел автоматизации с нуля.
Писал сам, набирал команду, и писали-анализировали-ковыряли-оптимизировали, при этом, старая система должна была не только поддерживаться, но развиваться в систему версии 1.5, которая работала совместно с новой системой версии 1.0, которая в свою очередь в версии 2.0 должа была заменить их обеих.
Получилось замечательно, компания получала в каждый нужный момент времени ту версию — которая была ей необходима, при этом проектирование принципиально новой системы не останавливалось ни на шаг.
Были конечно сложности с появлением одновременнно двух инструментариев — но все это решаемо, главное подобрать команду в которой решались вопросы проектирования и архитектуры.
Приветствую.
Приятно слышать в обсуждении знакомые нотки. Однако, не могу согласиться ни с одной из полярных позиций.
Скажу честно, я был в похожей ситуации. Правда самописной системе было на момент начала проекта 16 лет. Внедрение же, было сильно стимулировано американским капиталом, которому в значительной мере было важно иметь систему с «мировым именем» (прошу не относить это к преимуществам или недостаткам, имело место и то и другое).
Процесс внедрения и стандартизации процессов, безусловно, был похож на упомянутое натягивание. Но как специалист по этим самым процессам смело могу заявить, что большинство «спорных требований» были откровенным космосом. На вопрос «Как это у вас работает сейчас?» ответом был стыдливый взгляд в пол и бубнеж про то как этого не хватает и какие красивые мечты вместе с этим чем-то. Не могу не заметить что обратные ситуации так же имели место, но в гораздо меньшем количестве.
Не спорю, в итоге все получилось «прекрасно». Если сначала собирались сделать лимузин с бассейном, то получился космический корабль с привязанной на поводке лайкой в открытом космосе.
По поводу проектирования подобной системы. Категорически не согласен с тем что подобные данные нужно интегрировать (кстати какими средствами вы считаете это осуществить?) в что-то стороннее и затем строить там мифические отчеты. Это влечет за собой ровно тот же самый риск «ошибок, ошибок» только уже упущенных на стадии проектирования интерфейсов. Исправить баг в таком случае — несколько месяцев. А в случае, если это не баг, а требование — конфликт либо доп разработка. В любом случае автоматизируя хаос получается, как правило, автоматизированный хаос.
На мой взгляд необходим корректно спроектированный программный продукт который будет отвечать тем требованиям, которые актуальны для конкретного бизнеса. Сделать это вполне реально. Правда, желательно, что бы клиент не залезал отчаянно в детали разработки и не лез с советами.
Вероятнее всего, для описанного клиента нужно не только ERP систему, но и WMS. Причем это могут и не быть упомянутые «мировые имена». В любом случае, так ненавистные некоторым представителям хабробщества специалисты по бизнес-процессам именно в такой связке успешно достигают необходимых результатов, даже когда заказчик не в состоянии вменяемо описать собственные требования.
К слову, именно как представитель этой весьма противоречивой профессии уверяю вас, что под маской «специалиста по настраиваемой коробочной системе», как правило, кроется человек для которого нет ничего уникального в сложной системе которую товарищи Василий и Инокентий писали много лет. Собственно «дикие денжищи» уплачиваются не за разработку 10 страниц кода, а за то что бы этот самый код достиг поставленных целей (самое время нарисовать мысленный треугольник), причем не так как разработчик понял, а так как этого требует клиент.
Ну, это если для кого-то секрет.
По поводу запуска.
Саботаж, безусловно, может быть. Но спешу вас заверить, что будет он только в случае если проектом не управлять вовсе. С каждыми устоями, страхами можно и нужно бороться (вспоминая Евгения Базарова). Нет ничего сложного (при указанных вводных данных) в том что бы:
1. Организовать процесс обучения
2. Запустить систему в режиме опытной эксплуатации
3. Составить план поэтапного, в данном случае модульного запуска в продакшн.
Конечно, многие проекты валятся на этом. Бесспорно, для хорошей организации нужен опыт решения таких задач. 150 человек? Быстро не получится, но и не 10 лет, конечно.
Основной вопрос всей этой пьянки — строгое определение цели проекта и объема затрат. Что и за какую сумму/время хочет получить заказчик. Хочет кнопку «Сделать очень хорошо» — дороже чем можно себе позволить.
Как говорит один мой хороший знакомый: «Возможно все».
Приятно слышать в обсуждении знакомые нотки. Однако, не могу согласиться ни с одной из полярных позиций.
Скажу честно, я был в похожей ситуации. Правда самописной системе было на момент начала проекта 16 лет. Внедрение же, было сильно стимулировано американским капиталом, которому в значительной мере было важно иметь систему с «мировым именем» (прошу не относить это к преимуществам или недостаткам, имело место и то и другое).
Процесс внедрения и стандартизации процессов, безусловно, был похож на упомянутое натягивание. Но как специалист по этим самым процессам смело могу заявить, что большинство «спорных требований» были откровенным космосом. На вопрос «Как это у вас работает сейчас?» ответом был стыдливый взгляд в пол и бубнеж про то как этого не хватает и какие красивые мечты вместе с этим чем-то. Не могу не заметить что обратные ситуации так же имели место, но в гораздо меньшем количестве.
Не спорю, в итоге все получилось «прекрасно». Если сначала собирались сделать лимузин с бассейном, то получился космический корабль с привязанной на поводке лайкой в открытом космосе.
По поводу проектирования подобной системы. Категорически не согласен с тем что подобные данные нужно интегрировать (кстати какими средствами вы считаете это осуществить?) в что-то стороннее и затем строить там мифические отчеты. Это влечет за собой ровно тот же самый риск «ошибок, ошибок» только уже упущенных на стадии проектирования интерфейсов. Исправить баг в таком случае — несколько месяцев. А в случае, если это не баг, а требование — конфликт либо доп разработка. В любом случае автоматизируя хаос получается, как правило, автоматизированный хаос.
На мой взгляд необходим корректно спроектированный программный продукт который будет отвечать тем требованиям, которые актуальны для конкретного бизнеса. Сделать это вполне реально. Правда, желательно, что бы клиент не залезал отчаянно в детали разработки и не лез с советами.
Вероятнее всего, для описанного клиента нужно не только ERP систему, но и WMS. Причем это могут и не быть упомянутые «мировые имена». В любом случае, так ненавистные некоторым представителям хабробщества специалисты по бизнес-процессам именно в такой связке успешно достигают необходимых результатов, даже когда заказчик не в состоянии вменяемо описать собственные требования.
К слову, именно как представитель этой весьма противоречивой профессии уверяю вас, что под маской «специалиста по настраиваемой коробочной системе», как правило, кроется человек для которого нет ничего уникального в сложной системе которую товарищи Василий и Инокентий писали много лет. Собственно «дикие денжищи» уплачиваются не за разработку 10 страниц кода, а за то что бы этот самый код достиг поставленных целей (самое время нарисовать мысленный треугольник), причем не так как разработчик понял, а так как этого требует клиент.
Ну, это если для кого-то секрет.
По поводу запуска.
Саботаж, безусловно, может быть. Но спешу вас заверить, что будет он только в случае если проектом не управлять вовсе. С каждыми устоями, страхами можно и нужно бороться (вспоминая Евгения Базарова). Нет ничего сложного (при указанных вводных данных) в том что бы:
1. Организовать процесс обучения
2. Запустить систему в режиме опытной эксплуатации
3. Составить план поэтапного, в данном случае модульного запуска в продакшн.
Конечно, многие проекты валятся на этом. Бесспорно, для хорошей организации нужен опыт решения таких задач. 150 человек? Быстро не получится, но и не 10 лет, конечно.
Основной вопрос всей этой пьянки — строгое определение цели проекта и объема затрат. Что и за какую сумму/время хочет получить заказчик. Хочет кнопку «Сделать очень хорошо» — дороже чем можно себе позволить.
Как говорит один мой хороший знакомый: «Возможно все».
Типичная речь, типичного пиарщика ERP систем…
Куча красивых слов и правильных выражений, тут и план обучения и модульный запуск в продакшн и страшные заклинания ERP+WMS… Не согласится сложно.
Вот только потратив кучу бабла на вас, организация (скорее всего, но не факт) поймет, что вы рассказываете им прописные истины за просто огромные деньги. И это того не стоит…
Опять же пример из личной жизни, который и щас наблюдаю… кстати он про WMS ;)
Большая компания с огромным складом. Система отгрузок построена на 1С + Бумага… ну да, по вашим меркам это каменный век.
В общем приходит крутейшая российская компания и говорит, что вы сами не понимаете как надо управлять складом с большим грузопотоком. Тут у вас не по правильным бизнеспроцессам, а там вообще не понятно зачем на бумаге пишете и переносите потом в комп. При этом говорит правильные и красивые слова… прямо как у вас… ну руководство то понимает, что обороты растут, что слова правильные и вроде как надо что-то делать. Принимают решение внедрять WMS.
Внедренцы грозились снизить количество ошибок на складе, наладить контроль всего и много еще чего. Расписывали просто горы золотые. Очень убедительно показывали на примерах работы контор мирового масштаба, как их правильные бизнеспроцессы рулят…
Итог всего этого безобразия: Сколько миллионов было угрохано во внедрение я рассказать по понятным причинам не могу. Еще больше было потеряно при простоях склада во время внедрения. Процент ошибок на складе 7%. Пришлось сменить кучу персонала на более высокооплачиваемых т.к. к работе с ТСД простого пролетария не подпустишь, они их банально ломают. Пришлось создать и кормить целый отдел из 12 человек которые занимаются анализом и оптимизацией бизнес процессов. Куча нервов у персонала, многие ценные сотрудники уволились просто не выдержав нервотрепки. При этом саботажа не было, все старались — руководство не поскупилось на пиар новинок среди персонала.
Сейчас руководство сильно чешет репу… ошибок ДО внедрения было 3%, на работу можно было брать любых, извините за выражение, баранов их быстро дрессировали на работу с бумажными формами.
По другим показателям тоже нет улучшения. И это только внешние показатели, про жестокие глюки в софте я просто молчу.
Этот цирк идет уже больше 3-х лет. Руководство не раз пожалело о своем решении…
Что я хочу этим сказать? Помните старую поговорку, что с дуру можно некоторые вещи в трех местах сломать?
Так вот при нормальном подходе к решению задач, все будет хорошо у собственной команды разработчиков.
А при не нормальном не спасет никто и ничто, будет маразм и бардак…
P.S. Фразу «Собственно «дикие денжищи» уплачиваются не за разработку 10 страниц кода, а за то что бы этот самый код достиг поставленных целей (самое время нарисовать мысленный треугольник), причем не так как разработчик понял, а так как этого требует клиент. » — утащу на цитату… просто золотая фраза пиарщика…
Куча красивых слов и правильных выражений, тут и план обучения и модульный запуск в продакшн и страшные заклинания ERP+WMS… Не согласится сложно.
Вот только потратив кучу бабла на вас, организация (скорее всего, но не факт) поймет, что вы рассказываете им прописные истины за просто огромные деньги. И это того не стоит…
Опять же пример из личной жизни, который и щас наблюдаю… кстати он про WMS ;)
Большая компания с огромным складом. Система отгрузок построена на 1С + Бумага… ну да, по вашим меркам это каменный век.
В общем приходит крутейшая российская компания и говорит, что вы сами не понимаете как надо управлять складом с большим грузопотоком. Тут у вас не по правильным бизнеспроцессам, а там вообще не понятно зачем на бумаге пишете и переносите потом в комп. При этом говорит правильные и красивые слова… прямо как у вас… ну руководство то понимает, что обороты растут, что слова правильные и вроде как надо что-то делать. Принимают решение внедрять WMS.
Внедренцы грозились снизить количество ошибок на складе, наладить контроль всего и много еще чего. Расписывали просто горы золотые. Очень убедительно показывали на примерах работы контор мирового масштаба, как их правильные бизнеспроцессы рулят…
Итог всего этого безобразия: Сколько миллионов было угрохано во внедрение я рассказать по понятным причинам не могу. Еще больше было потеряно при простоях склада во время внедрения. Процент ошибок на складе 7%. Пришлось сменить кучу персонала на более высокооплачиваемых т.к. к работе с ТСД простого пролетария не подпустишь, они их банально ломают. Пришлось создать и кормить целый отдел из 12 человек которые занимаются анализом и оптимизацией бизнес процессов. Куча нервов у персонала, многие ценные сотрудники уволились просто не выдержав нервотрепки. При этом саботажа не было, все старались — руководство не поскупилось на пиар новинок среди персонала.
Сейчас руководство сильно чешет репу… ошибок ДО внедрения было 3%, на работу можно было брать любых, извините за выражение, баранов их быстро дрессировали на работу с бумажными формами.
По другим показателям тоже нет улучшения. И это только внешние показатели, про жестокие глюки в софте я просто молчу.
Этот цирк идет уже больше 3-х лет. Руководство не раз пожалело о своем решении…
Что я хочу этим сказать? Помните старую поговорку, что с дуру можно некоторые вещи в трех местах сломать?
Так вот при нормальном подходе к решению задач, все будет хорошо у собственной команды разработчиков.
А при не нормальном не спасет никто и ничто, будет маразм и бардак…
P.S. Фразу «Собственно «дикие денжищи» уплачиваются не за разработку 10 страниц кода, а за то что бы этот самый код достиг поставленных целей (самое время нарисовать мысленный треугольник), причем не так как разработчик понял, а так как этого требует клиент. » — утащу на цитату… просто золотая фраза пиарщика…
Ну и конечно все проблемы решит именно ваша ERP система… :)
Ох, как знакомо. У меня в компании сейчас такая же ситуация, если не сложнее.
Лет 6 скорее, есть некая система в которой ведётся Warehouse, вёлся Accounting и всяческие Invoices, CUstomer Orders и т.п. Написано на VB6 + MS SQL, разработчиков сменилось штук 6-7 как говорят. Плюс еще куча сторонних софтов от QuickBook до Excel в Dropbox.
И вот есть желание перейти на какую-нибудь open source, freeware ERP с возможностями CRM. Но смотря на OpenBravo и OpenERP не выполняются главные требования в которых противоречение, быстрая работа интерфейса и работа в облаке (Интернете).
Вот и буксуем, что порой кажется было бы проще ряд бизнес процессов уже давно написать самим
Лет 6 скорее, есть некая система в которой ведётся Warehouse, вёлся Accounting и всяческие Invoices, CUstomer Orders и т.п. Написано на VB6 + MS SQL, разработчиков сменилось штук 6-7 как говорят. Плюс еще куча сторонних софтов от QuickBook до Excel в Dropbox.
И вот есть желание перейти на какую-нибудь open source, freeware ERP с возможностями CRM. Но смотря на OpenBravo и OpenERP не выполняются главные требования в которых противоречение, быстрая работа интерфейса и работа в облаке (Интернете).
Вот и буксуем, что порой кажется было бы проще ряд бизнес процессов уже давно написать самим
Вот openbravoru.cloudapp.net/openbravo/ на три месяца развернул в облаке Windows Azure сервер с Openbravo 3, интерфейс работает намного быстрей интернет клиента 1С. Демо вход пока только с ролью бухгалтера Имя: RuFin Пароль: finru Перевод делаю самостоятельно, так что пока много чего ещё надо сделать, но система очень не плохая, плюсы модульность и большой упор на бухгалтерию и управление торговлей, двойная запись(дебит-кредит) присутствует :)
Извините, заказчик не Норвежский?
ИМХО, тут проблема не в ERP, а в кадрах…
За 10 лет я думаю много что изменилось — от законодательства и условий работы с клиентами, до состава персонала… И неужели за 10 лет никто не поднял вопрос перед руководством, что данный продукт — тупиковый? Никто не задумался, не проанализировал?
За 10 лет я думаю много что изменилось — от законодательства и условий работы с клиентами, до состава персонала… И неужели за 10 лет никто не поднял вопрос перед руководством, что данный продукт — тупиковый? Никто не задумался, не проанализировал?
Что-то нигде в статье не нашел — а сколько же человек занимались разработкой собственной ERP и какая у них была еще помимо этого работа? Может там один разработчик был на полставки? Сам попал в такую ситуацию, когда 2-3 человека 5 лет даже не допиливали типовое решение под нужды предприятия.
И еще одно — не дай вам бог что-то внедрять при полном отсутствии инициативы со стороны руководства.
И еще одно — не дай вам бог что-то внедрять при полном отсутствии инициативы со стороны руководства.
Может стоит перенести из тематического в блог компании..?
Хорошая статья. Есть о чем задуматься.
Но почему-то я делаю вывод, что разработка чего-то для выполнения функций ERP внутри компании — далеко не провальная идея. Провальная идея — заниматься этим по остаточному принципу. У меня есть подозрение, что найм сильных разработчиков, архитектора и аналитика, осознание целей и задач компании управленческим составом, работа с хотелками пользователей в итоге обойдутся не дороже покупки и внедрения коробочной ERP. Возможно получится даже лучше чем космический корабль с привязанной снаружи лайкой.
Но почему-то я делаю вывод, что разработка чего-то для выполнения функций ERP внутри компании — далеко не провальная идея. Провальная идея — заниматься этим по остаточному принципу. У меня есть подозрение, что найм сильных разработчиков, архитектора и аналитика, осознание целей и задач компании управленческим составом, работа с хотелками пользователей в итоге обойдутся не дороже покупки и внедрения коробочной ERP. Возможно получится даже лучше чем космический корабль с привязанной снаружи лайкой.
Пять гребаных лет мы приспосабливались к покупной системе с мировым именем, внедренную с привлечением интегратора с мировым же именем. Три гребаных года из них наши магазины имели проблемы со снабжением, а наши склады были завалены никому не нужной фигней.
Но благодаря этому внедрению, мы поняли многое, многому научились, многого перестали бояться. Она нас не убила, а сделала сильнее. Из этой системы мы извлекли множество замечательных идей, которые нам не приходили в голову раньше. Шаг за шагом, мы откусывали от этой системы кусочек функционала и реализовывали его так, как требуют того наши бизнесс процессы. Благодаря этому внедрению, наш бизнесс понял, какие же в самом деле замечательный у него инхауз.
Но благодаря этому внедрению, мы поняли многое, многому научились, многого перестали бояться. Она нас не убила, а сделала сильнее. Из этой системы мы извлекли множество замечательных идей, которые нам не приходили в голову раньше. Шаг за шагом, мы откусывали от этой системы кусочек функционала и реализовывали его так, как требуют того наши бизнесс процессы. Благодаря этому внедрению, наш бизнесс понял, какие же в самом деле замечательный у него инхауз.
За всю свою многолетнюю практику я ни разу не слышал об успешном внедрении покупных ERP систем в какой-либо компании. «Успешное» в данном случае — это когда соблюдены сроки, уложились в бюджет и решили все изначально заявленные задачи, т.е. про удовлетворенность заказчиков я даже не упоминаю (ее никогда не бывает, наверное).
С другой стороны, каждое такое внедрение в результате (т.е. после десятка скандалов и некоторой доработки напильником) все-таки позволяет заказчикам решать свои проблемы и автоматизировать бизнес, и при этом обходится значительно дешевле, чем создание похожей системы с нуля силами внутренних разработчиков.
Если не секрет, годовой бюджет вашего «замечательного инхауза» какой?
С другой стороны, каждое такое внедрение в результате (т.е. после десятка скандалов и некоторой доработки напильником) все-таки позволяет заказчикам решать свои проблемы и автоматизировать бизнес, и при этом обходится значительно дешевле, чем создание похожей системы с нуля силами внутренних разработчиков.
Если не секрет, годовой бюджет вашего «замечательного инхауза» какой?
>> годовой бюджет
Увы я не допущен к этой информации в своей компании.
>> создание похожей системы с нуля
В нашем случае имело место быть «до основания, а за тем...». Впрочем ранее существовавшая самописка мало кого удовлетворяла, в том числе и замечательный инхауз. Имели место огромные проблемы с масштабированием. Перемены, определенно, были нужны, но цена вопроса оказалась на деле не адекватно велика, это, косвенным образом, признал и тогдашний директорат, признавший проект в целом успешным. Нынешний видит в том внедрении источник всех бед компании. С моей точки зрения, не совсем справедливо.
>> все-таки позволяет заказчикам решать свои проблемы и автоматизировать бизнес
Если в этой фразе использовать «как-то», в качестве характеристики способа решения своих проблем, это будет хорошо сочетаться и с имеющимся у меня опытом.
Проблема в том, что вкладывая не малые деньги в покупную систему, это «как-то», для бизнеса возникает неожиданно.
Увы я не допущен к этой информации в своей компании.
>> создание похожей системы с нуля
В нашем случае имело место быть «до основания, а за тем...». Впрочем ранее существовавшая самописка мало кого удовлетворяла, в том числе и замечательный инхауз. Имели место огромные проблемы с масштабированием. Перемены, определенно, были нужны, но цена вопроса оказалась на деле не адекватно велика, это, косвенным образом, признал и тогдашний директорат, признавший проект в целом успешным. Нынешний видит в том внедрении источник всех бед компании. С моей точки зрения, не совсем справедливо.
>> все-таки позволяет заказчикам решать свои проблемы и автоматизировать бизнес
Если в этой фразе использовать «как-то», в качестве характеристики способа решения своих проблем, это будет хорошо сочетаться и с имеющимся у меня опытом.
Проблема в том, что вкладывая не малые деньги в покупную систему, это «как-то», для бизнеса возникает неожиданно.
Это довольно просто посчитать. (Количество разработчиков) Х (средняя зарплата) Х (1.82 налоги). Никто же не требует точных цифр, достаточно определить порядок (думаю, что будет где-то от 200 до 400К USD в год).
Понимаете, внешнее внедрение хорошо (для бизнеса) еще и тем, что деньги платятся (если заказчики, конечно, не совсем лохи) за некие объективные результаты. Инхауз разработчикам деньги надо платить два раза в месяц, независимо от результатов. Дальше — налоги. НДС с внешнего внедрения компании идет в зачет, а на внутренних разработчиков — наоборот, платится. Дальше — отпуска и больничные, текучка кадров, обучение, эффективность менеджмента… И т.д. и т.п.
Короче, результат в обоих случаях получается сильно далеким от идеала, кто спорит? Просто инхауз разработка в не-ИТ компании всегда обходится бизнесу дороже и дольше, чем внешнее внедрение, это факт.
Понимаете, внешнее внедрение хорошо (для бизнеса) еще и тем, что деньги платятся (если заказчики, конечно, не совсем лохи) за некие объективные результаты. Инхауз разработчикам деньги надо платить два раза в месяц, независимо от результатов. Дальше — налоги. НДС с внешнего внедрения компании идет в зачет, а на внутренних разработчиков — наоборот, платится. Дальше — отпуска и больничные, текучка кадров, обучение, эффективность менеджмента… И т.д. и т.п.
Короче, результат в обоих случаях получается сильно далеким от идеала, кто спорит? Просто инхауз разработка в не-ИТ компании всегда обходится бизнесу дороже и дольше, чем внешнее внедрение, это факт.
В описанном мною случае привлечение внешнего ресурса не повлекло за собой сброс внутреннего. Внутренний был использован для реализации переинтеграции всего со всем и для стабилизации постинтеграциионных флуктуаций. Более того, на проект пришлось нанять еще целое подразделение. Внутренний штат айти распух втрое. Бизнесу, для работы в новой системе пришлось тоже существенно расширять кадры, после внедрения, для управления теми же процессами, потребовался существенно больший штат.
>> Это довольно просто посчитать.
У нас разработчиков — по пальцам перечесть. Точно не знаю их числа, разрабы размазаны по подразделениям и регионам. И мне кажется это большое заблуждение, что для разработки собственной ERP требуется большое количество людей. Здесь решает квалификация. А при поддержке покупного, все равно нужен кто-то достаточно квалифицированный, кто будет осуществлять функции третьей линии поддержки, или же кто способен дать экспертную оценку адекватности цены доработки запрошенную аутсорсером.
>> Просто инхауз разработка в не-ИТ компании всегда обходится бизнесу дороже и дольше, чем внешнее внедрение, это факт.
Не могу тут спорить. Я не располагаю доступом к финансовой информации. В идеале это действительно должно бы так быть, но во времена кризиса наша компания сбрасывала внешние пассивы, забирала на себя поддержку и развитие, расширяла собственный штат.
>> Это довольно просто посчитать.
У нас разработчиков — по пальцам перечесть. Точно не знаю их числа, разрабы размазаны по подразделениям и регионам. И мне кажется это большое заблуждение, что для разработки собственной ERP требуется большое количество людей. Здесь решает квалификация. А при поддержке покупного, все равно нужен кто-то достаточно квалифицированный, кто будет осуществлять функции третьей линии поддержки, или же кто способен дать экспертную оценку адекватности цены доработки запрошенную аутсорсером.
>> Просто инхауз разработка в не-ИТ компании всегда обходится бизнесу дороже и дольше, чем внешнее внедрение, это факт.
Не могу тут спорить. Я не располагаю доступом к финансовой информации. В идеале это действительно должно бы так быть, но во времена кризиса наша компания сбрасывала внешние пассивы, забирала на себя поддержку и развитие, расширяла собственный штат.
Так никто же и не спорит, что при желании можно найти разумный компромисс в виде объединения всех недостатков обоих способов разработки.
«Здесь решает квалификация» — т.е. откуда-то вдруг в непрофильной компании появятся программисты, более квалифицированные, чем в компании, на этом самом софте специализирующейся?
Если компания, условно говоря, торгует пончиками, но при этом разрабатывает и внедряет ERP лучше профессионалов, то почему бы ей помимо торговли пончиками еще и на этом рынке не зарабатывать?
Поведение компаний в момент кризиса редко поддаются разумному объяснению и может быть просто любым. Кто-то окэшивается и закукливается, кто-то, наоборот, использует возможности для взрывного развития. Вот ваше руководство так решило кризис победить — их право.
«Здесь решает квалификация» — т.е. откуда-то вдруг в непрофильной компании появятся программисты, более квалифицированные, чем в компании, на этом самом софте специализирующейся?
Если компания, условно говоря, торгует пончиками, но при этом разрабатывает и внедряет ERP лучше профессионалов, то почему бы ей помимо торговли пончиками еще и на этом рынке не зарабатывать?
Поведение компаний в момент кризиса редко поддаются разумному объяснению и может быть просто любым. Кто-то окэшивается и закукливается, кто-то, наоборот, использует возможности для взрывного развития. Вот ваше руководство так решило кризис победить — их право.
>> откуда-то вдруг в непрофильной компании появятся программисты, более квалифицированные, чем в компании, на этом самом софте специализирующейся?
Почему вдруг нет? Почему квалифицированные кадры должны сосредотачиваться именно в софтверных компаниях? Среди моего окружения я наблюдал достаточно случаев, когда устав от этих бесконечных внедрений, сегодня — здесь, завтра — там, есть проект — живешь, нет — лапу сосешь, но набрав при том себе внушительное резюме, внушительную коллекцию сертификатов, люди уходят в тепленький инхауз сидеть на одном месте, под одним ПМ, без авралов, бесконечных командировок и простоев. Таких случаев мне известно на столько много, что я даже полагал что это тенденция. Разве не так?
>> Если компания, условно говоря, торгует пончиками, но при этом разрабатывает и внедряет ERP лучше профессионалов, то почему бы ей помимо торговли пончиками еще и на этом рынке не зарабатывать?
Для того чтобы внедрить ERP и продать ее требуются совершенно разные квалификации. Нет?
Почему вдруг нет? Почему квалифицированные кадры должны сосредотачиваться именно в софтверных компаниях? Среди моего окружения я наблюдал достаточно случаев, когда устав от этих бесконечных внедрений, сегодня — здесь, завтра — там, есть проект — живешь, нет — лапу сосешь, но набрав при том себе внушительное резюме, внушительную коллекцию сертификатов, люди уходят в тепленький инхауз сидеть на одном месте, под одним ПМ, без авралов, бесконечных командировок и простоев. Таких случаев мне известно на столько много, что я даже полагал что это тенденция. Разве не так?
>> Если компания, условно говоря, торгует пончиками, но при этом разрабатывает и внедряет ERP лучше профессионалов, то почему бы ей помимо торговли пончиками еще и на этом рынке не зарабатывать?
Для того чтобы внедрить ERP и продать ее требуются совершенно разные квалификации. Нет?
«Почему вдруг нет? Почему квалифицированные кадры должны сосредотачиваться именно в софтверных компаниях?» — возможно, потому, что их в софтверных компаниях нанимают ИТ-профессионалы, а не продавцы товаров народного потребления?
«Для того чтобы внедрить ERP и продать ее требуются совершенно разные квалификации.» — а для того, чтобы торговать пончиками и делать ERP?
«Для того чтобы внедрить ERP и продать ее требуются совершенно разные квалификации.» — а для того, чтобы торговать пончиками и делать ERP?
Вы передергиваете… в нормальных конторах тех директор который и рулит процессом.
Расскажите, пожалуйста, каким именно «процессом» рулит в «нормальных конторах» тех. директор?
Ну вот возьмем, например, обычную торговую контору (где как раз потребность в ERP максимальна). Там есть департамент закупок, есть департамент продаж, есть склад… Штук 300 рабочих станций, десяток серверов, офисная АТС. Весь этот зоопарк обслуживают 3-4 сисадмина (больше просто ненужно). И в такой конторе, по-вашему, есть «технический директор»?!!!
А ведь оборот у такой конторы — сотни миллионов долларов в год. И без ERP со всем этим — фиг справишься.
Ну вот возьмем, например, обычную торговую контору (где как раз потребность в ERP максимальна). Там есть департамент закупок, есть департамент продаж, есть склад… Штук 300 рабочих станций, десяток серверов, офисная АТС. Весь этот зоопарк обслуживают 3-4 сисадмина (больше просто ненужно). И в такой конторе, по-вашему, есть «технический директор»?!!!
А ведь оборот у такой конторы — сотни миллионов долларов в год. И без ERP со всем этим — фиг справишься.
Вы тут в соседней ветке упомянули БиТ…
Если вы приводите в пример кадровую политику именно этой организации, смею вас заверить, многие торговцы пончиками, производят куда более тщательный отбор нанимаемого персонала. А привлечение БиТ к проекту вовсе не уберегает заказчика от того, что на проект придет куча сброда, не прижившегося на другом проекте. И это при том, что БиТ, сам по себе, не так уж и плох, и даже хорош.
Если вы приводите в пример кадровую политику именно этой организации, смею вас заверить, многие торговцы пончиками, производят куда более тщательный отбор нанимаемого персонала. А привлечение БиТ к проекту вовсе не уберегает заказчика от того, что на проект придет куча сброда, не прижившегося на другом проекте. И это при том, что БиТ, сам по себе, не так уж и плох, и даже хорош.
Стоит упомянуть, что есть «инхауз» системы, которые в дальнейшем вытекают наружу и становятся отдельными и хорошими продуктами для компаний со схожим процессом работы (openerp, openbravo — всё это писалось конкретно для работы, а потом вытекло в сторонний продукт)
Внедрение крупных систем происходит не один месяц. Это значит, что вы команду внедряльщика фактически нанимаете на фултайм на несколько лет. В цену одного внешнего сотрудника входит не только его ЗП, но и ЗП фирмы от которой он пришел. Так что далеко не факт, что будет дешевле.
А внешний сотрудниук который во время внедрения появляется на 2 часа в день… ну вы сами понимаете, что это смешно.
В моей маленькой деревне 1 час внедренца со стороны франчей 1С стоит 900руб. При 40 часовой рабочей неделе получаем примерно 150т.р. в месяц. Если брать на сотрудника себе на постоянку, то его ЗП будет примерно 50-60 т.р. даже со всеми вашими накрутками налогов и т.д. получается дешевле своего держать… Ну это я так к примеру посчитал.
И опять же почему вы все меряете деньгами.
Ну да, инхауз разработчики могут обойтись дороже внешнего внедряльщика. Тут никто не спорит.
Но почему это всегда плохо?
Своего сотрудника проще контролировать, его легче мотивировать. Он всегда под рукой. Процесс отбора сотрудников тоже происходит под контролем. Опять же своих проще контролировать отделу информационной безопасности. Можно выбирать любые технологии, а не только ту единственную которую может предложить внедряльщик.
В случае, когда внешние внедрельцы получаются дешевле — фирма знает за что переплачивает. И часто это того стоит.
А внешний сотрудниук который во время внедрения появляется на 2 часа в день… ну вы сами понимаете, что это смешно.
В моей маленькой деревне 1 час внедренца со стороны франчей 1С стоит 900руб. При 40 часовой рабочей неделе получаем примерно 150т.р. в месяц. Если брать на сотрудника себе на постоянку, то его ЗП будет примерно 50-60 т.р. даже со всеми вашими накрутками налогов и т.д. получается дешевле своего держать… Ну это я так к примеру посчитал.
И опять же почему вы все меряете деньгами.
Ну да, инхауз разработчики могут обойтись дороже внешнего внедряльщика. Тут никто не спорит.
Но почему это всегда плохо?
Своего сотрудника проще контролировать, его легче мотивировать. Он всегда под рукой. Процесс отбора сотрудников тоже происходит под контролем. Опять же своих проще контролировать отделу информационной безопасности. Можно выбирать любые технологии, а не только ту единственную которую может предложить внедряльщик.
В случае, когда внешние внедрельцы получаются дешевле — фирма знает за что переплачивает. И часто это того стоит.
«Своего сотрудника проще контролировать, его легче мотивировать. Он всегда под рукой. Процесс отбора сотрудников тоже происходит под контролем.» — вот об этом я и написал чуть ниже, да.
Любая фирма, успешно зарабатывающая на продаже пончиков, способна справиться с разработкой ERP, просто наняв программистов себе в штат. Офигеть.
Ну а приведенные экономические расчеты, извините, не буду комментировать, ладно?
Любая фирма, успешно зарабатывающая на продаже пончиков, способна справиться с разработкой ERP, просто наняв программистов себе в штат. Офигеть.
Ну а приведенные экономические расчеты, извините, не буду комментировать, ладно?
Да это не эконмические рассчеты… это я привел цифры до которые что называется перед глазами…
И да… Любая фирма, успешно зарабатывающая на продаже пончиков, способна справиться с разработкой ERP, просто наняв программистов себе в штат.
Ибо разработкой будет рулить не шеф повар по изготовлению пончиков, а нанятый грамотный начальник отдела разработки…
И да… Любая фирма, успешно зарабатывающая на продаже пончиков, способна справиться с разработкой ERP, просто наняв программистов себе в штат.
Ибо разработкой будет рулить не шеф повар по изготовлению пончиков, а нанятый грамотный начальник отдела разработки…
dzhe, я внимательнейшим образом обдумал множество озвученных Вами тезисов (хоть и не могу похвастать, что обдумал их все), и даже несколько затрудняюсь определиться в ответ на какой из Ваших постов выложить результат этих мыслей, потому выбрал первый попавшийся.
Мне кажется следует разделить понятия «учетная система» и «система планирования ресурсов». Учетная система просто регестрирует бизнесс-факты, система планирования принимает бизнес-значимые решения на основе этих данных.
Разработка собственной учетной системы действительно может занять огромное количество человеко-лет. Всяческие справочники, реестры, регистры, работа с кассовым оборудованием, сканерами и пр. пр. В индустрии действительно присутствует множество готовых решений, в том числе и коробочных. Использовать внешний ресурс для внедрения подобных систем, интеграции, обучения персонала — очевидное и верное решение, это действительно обойдется многократ дешевле нежели реализация собственными силами.
Однако система планирования — совсем другой разговор. Здесь нет устоявшийся практик, каждый бизнес владеет собственным ноу-хау, который позволяет ему быть более или же менее успешным. Это знание аккумулируется в подразделениями бизнес технологий, постоянно оттачиваетя, уточняется и исправляется бизнес аналитиками. Отдавать эти подразделения на аутсорс — очень большой риск потерять весь бизнес. Реализация же этих технологий, как правило не требует большого количества ресурса. Один — два толковых разработчика с лихвой покроют потребности каждого из контуров (финансового, товарного...) организации весьма внушительных размеров. Для реализации алгоритмов ассортиментного планирования, прогнозирования, расчета потребностей, выбора схемы снабжения, оптимального поставщика, формирования заказов, графика оплат, и пр. пр. не на столько уж и много кодинга требуется. Но эти алгоритмы постоянно уточняются, изменяются, исправляются на протяжении всего цикла жизни предприятия, и использование внешнего ресурса, здесь, оказывается не адекватно дорого. Как я уже говорил, аналитику и технологии во внешний ресурс — не отдашь, а удельная доля работ разработчиков в этих доработках не так уж и велика.
Мне кажется следует разделить понятия «учетная система» и «система планирования ресурсов». Учетная система просто регестрирует бизнесс-факты, система планирования принимает бизнес-значимые решения на основе этих данных.
Разработка собственной учетной системы действительно может занять огромное количество человеко-лет. Всяческие справочники, реестры, регистры, работа с кассовым оборудованием, сканерами и пр. пр. В индустрии действительно присутствует множество готовых решений, в том числе и коробочных. Использовать внешний ресурс для внедрения подобных систем, интеграции, обучения персонала — очевидное и верное решение, это действительно обойдется многократ дешевле нежели реализация собственными силами.
Однако система планирования — совсем другой разговор. Здесь нет устоявшийся практик, каждый бизнес владеет собственным ноу-хау, который позволяет ему быть более или же менее успешным. Это знание аккумулируется в подразделениями бизнес технологий, постоянно оттачиваетя, уточняется и исправляется бизнес аналитиками. Отдавать эти подразделения на аутсорс — очень большой риск потерять весь бизнес. Реализация же этих технологий, как правило не требует большого количества ресурса. Один — два толковых разработчика с лихвой покроют потребности каждого из контуров (финансового, товарного...) организации весьма внушительных размеров. Для реализации алгоритмов ассортиментного планирования, прогнозирования, расчета потребностей, выбора схемы снабжения, оптимального поставщика, формирования заказов, графика оплат, и пр. пр. не на столько уж и много кодинга требуется. Но эти алгоритмы постоянно уточняются, изменяются, исправляются на протяжении всего цикла жизни предприятия, и использование внешнего ресурса, здесь, оказывается не адекватно дорого. Как я уже говорил, аналитику и технологии во внешний ресурс — не отдашь, а удельная доля работ разработчиков в этих доработках не так уж и велика.
Дело в том, что «система планирования ресурсов» (в Ваших терминах) живет на данных, которые поставляются «учетной системой». Т.е. их нужно интегрировать (если уж это не одно целое). При этом все современные «учетные системы» позволяют кастомизировать себя по-всякому, и если уж строить свою собственную «систему планирования», то на основе инструментария, предлагаемого выбранной «системой учета», Вы согласны?
Теперь дальше: кто и как должен строить «систему планирования» и интегрировать ее с «системой учета»? Очевидно, что для того, чтобы результат получился хороший и относительно быстро — этим должны заниматься профессионалы. Допустим, средняя компания (годовой оборот порядка 50-100 миллионов долларов в год, персонал — порядка 150-300 человек) хочет решить эту задачу (а эта задача — именно для таких компаний, которые уперлись в потолок возможностей управления «архаичными» методами и вынуждены что-то менять). Если компания нанимает хотя бы 3-4 профессионалов (меньшими силами такую систему не создать за разумный срок, согласитесь), то себестоимость года разработки составит порядка 3.5*100000*12*1.82, т.е. около 7.5 миллиона рублей. В то же время покупка готового или внедрение доработанного решения обойдется где-то в два раза дешевле, при этом для текущих настроек достаточно нанять парочку гораздо более дешевых внедренцев. При этом результаты обоих способов будут сопоставимы, но экономически второй вариант будет все-таки более выгоден (хотя бы из-за того же НДС). А уж насколько плоха идея привязать всю компанию к полностью «самописному» уникальному решению организационно! Перечислю только несколько рисков: недостижение обозначенных задач в установленный срок, развал команды в процессе работы, уход ведущих разработчиков после окончания разработки, поиск на рынке людей для поддержки уникального решения и т.п.
Короче, я остаюсь при своем мнении, извините.
Теперь дальше: кто и как должен строить «систему планирования» и интегрировать ее с «системой учета»? Очевидно, что для того, чтобы результат получился хороший и относительно быстро — этим должны заниматься профессионалы. Допустим, средняя компания (годовой оборот порядка 50-100 миллионов долларов в год, персонал — порядка 150-300 человек) хочет решить эту задачу (а эта задача — именно для таких компаний, которые уперлись в потолок возможностей управления «архаичными» методами и вынуждены что-то менять). Если компания нанимает хотя бы 3-4 профессионалов (меньшими силами такую систему не создать за разумный срок, согласитесь), то себестоимость года разработки составит порядка 3.5*100000*12*1.82, т.е. около 7.5 миллиона рублей. В то же время покупка готового или внедрение доработанного решения обойдется где-то в два раза дешевле, при этом для текущих настроек достаточно нанять парочку гораздо более дешевых внедренцев. При этом результаты обоих способов будут сопоставимы, но экономически второй вариант будет все-таки более выгоден (хотя бы из-за того же НДС). А уж насколько плоха идея привязать всю компанию к полностью «самописному» уникальному решению организационно! Перечислю только несколько рисков: недостижение обозначенных задач в установленный срок, развал команды в процессе работы, уход ведущих разработчиков после окончания разработки, поиск на рынке людей для поддержки уникального решения и т.п.
Короче, я остаюсь при своем мнении, извините.
>> если уж строить свою собственную «систему планирования», то на основе инструментария, предлагаемого выбранной «системой учета», Вы согласны?
Отчасти. Если мы говорим лишь об штучной инсталляции такой «учетной системы», то вполне закономерно нагрузить ее и кастомным функционалом «планирования». Однако если мы желаем иметь ее множество инсталляций, например в каждом магазине, кои у нас исчисляются десятками, быть может сотнями, то расстановка кастомизированных версий коробочного изделия по существенно увеличивает количество рисков поддержки и обновления такого продукта.
Что касается рисков размазывания функций планирования по бизнес-подразделениям, не моих компетенций дело, но с моей точки зрения это тоже весьма весьма и рискованно.
Если смотреть с этой точки зрения, мне кажется абстрагирование бэк-офиса от фронт-офиса, не такая уж и плохая идея.
>> Если компания нанимает хотя бы 3-4 профессионалов
Я так полагаю, Вы сейчас говорите о случае, когда компания заведомо не имеет в своем штате сильной команды бизнес-технологов и аналитиков. Тогда да, привлечение внешнего ресурса — единственный выход. Но мне кажется естественным, если компания пожелает оставить знание об особенностях протекании своих бизнес-процессов на своей стороне. В этом случае даже привлечение внешнего ресурса не избавляет компанию от необходимости нанимать этих 3-4 профессионалов для аккумулирования опыта. В противном же случае, компания обречена на заключение долгосрочных отношений с подрядчиком, что полностью нивелирует весь профит от «эпизодичности» в потребности такого рода отношений.
>>Короче, я остаюсь при своем мнении, извините.
Я не имею целью Вас переубедить — ни в коем случае. Мне просто интересны Ваши тезисы. Они дополняют сложившуюся у меня картину бытия, побуждают меня к размышлениям.
Отчасти. Если мы говорим лишь об штучной инсталляции такой «учетной системы», то вполне закономерно нагрузить ее и кастомным функционалом «планирования». Однако если мы желаем иметь ее множество инсталляций, например в каждом магазине, кои у нас исчисляются десятками, быть может сотнями, то расстановка кастомизированных версий коробочного изделия по существенно увеличивает количество рисков поддержки и обновления такого продукта.
Что касается рисков размазывания функций планирования по бизнес-подразделениям, не моих компетенций дело, но с моей точки зрения это тоже весьма весьма и рискованно.
Если смотреть с этой точки зрения, мне кажется абстрагирование бэк-офиса от фронт-офиса, не такая уж и плохая идея.
>> Если компания нанимает хотя бы 3-4 профессионалов
Я так полагаю, Вы сейчас говорите о случае, когда компания заведомо не имеет в своем штате сильной команды бизнес-технологов и аналитиков. Тогда да, привлечение внешнего ресурса — единственный выход. Но мне кажется естественным, если компания пожелает оставить знание об особенностях протекании своих бизнес-процессов на своей стороне. В этом случае даже привлечение внешнего ресурса не избавляет компанию от необходимости нанимать этих 3-4 профессионалов для аккумулирования опыта. В противном же случае, компания обречена на заключение долгосрочных отношений с подрядчиком, что полностью нивелирует весь профит от «эпизодичности» в потребности такого рода отношений.
>>Короче, я остаюсь при своем мнении, извините.
Я не имею целью Вас переубедить — ни в коем случае. Мне просто интересны Ваши тезисы. Они дополняют сложившуюся у меня картину бытия, побуждают меня к размышлениям.
>… своими силами разрабатывала программный продукт для управления бизнес процессами
А зачем? Им разве не сказали, что уже есть готовые продукты?
А зачем? Им разве не сказали, что уже есть готовые продукты?
На самом деле это проблема не только (и даже, наверное, не столько) ERP систем.
Огромное количество компаний в России (насколько я знаю, в других странах это куда менее распространено), зарабатывающих деньги отнюдь не созданием ПО, считает нормальным содержать штат программистов-разработчиков, которые создают и потом годами дорабатывают какие-то внутренние системы и сервисы. В результате себестоимость этих весьма узкоспециализированных программ достигает просто астрономических величин! Я не шучу. Не раз сталкивался с внутренним софтом компании, решающим вполне себе рядовые проблемы и имеющим не один аналог на рынке ПО, но обошедшимся за годы разработки в несколько миллионов долларов. Один среднеквалифицированный программист обходится компании минимум в 30К USD в год (зарплата, налоги, помещения, техника и т.д.), десяток программистов — это уже 300К, три-четыре года разработки — и вот он, первый мегабакс! Обычно, конечно, все еще дороже.
Но ладно бы при этом хоть результат получался впечатляющий, так нет же: в большинстве случаев собственники и директора компаний качеством внутреннего софта категорически не удовлетворены (и это за такие-то деньги)…
Поэтому я всегда советую компаниям, которые не зарабатывают хлеб именно разработкой ПО (т.е. не профессионалы в этой области) ни в коем случае не нанимать индор программистов (максимум — пару внедренцев, но не разработчиков!).
Огромное количество компаний в России (насколько я знаю, в других странах это куда менее распространено), зарабатывающих деньги отнюдь не созданием ПО, считает нормальным содержать штат программистов-разработчиков, которые создают и потом годами дорабатывают какие-то внутренние системы и сервисы. В результате себестоимость этих весьма узкоспециализированных программ достигает просто астрономических величин! Я не шучу. Не раз сталкивался с внутренним софтом компании, решающим вполне себе рядовые проблемы и имеющим не один аналог на рынке ПО, но обошедшимся за годы разработки в несколько миллионов долларов. Один среднеквалифицированный программист обходится компании минимум в 30К USD в год (зарплата, налоги, помещения, техника и т.д.), десяток программистов — это уже 300К, три-четыре года разработки — и вот он, первый мегабакс! Обычно, конечно, все еще дороже.
Но ладно бы при этом хоть результат получался впечатляющий, так нет же: в большинстве случаев собственники и директора компаний качеством внутреннего софта категорически не удовлетворены (и это за такие-то деньги)…
Поэтому я всегда советую компаниям, которые не зарабатывают хлеб именно разработкой ПО (т.е. не профессионалы в этой области) ни в коем случае не нанимать индор программистов (максимум — пару внедренцев, но не разработчиков!).
скорей всего это зависит не от географического положения а от соотношения доходов и зарплат квалифицированных программиста. Для Германии, скажем, банку содержать разработчиков слишком дорого. А вот в Нигерии, например, дёшево. Но там нет разработчиков.
Возьмём что-то более приземлённое — например кормёжку. Можно заказывать готовые обеды для всех сотрудников у посторонней фирмы. А можно выделить помещение под кухню, нанять поваров и пр. Во втором случая явно непрофильная деятельность в ряде случаев будет предпочтительней (при большом количестве работников, скажем).
Возьмём что-то более приземлённое — например кормёжку. Можно заказывать готовые обеды для всех сотрудников у посторонней фирмы. А можно выделить помещение под кухню, нанять поваров и пр. Во втором случая явно непрофильная деятельность в ряде случаев будет предпочтительней (при большом количестве работников, скажем).
Не географического, а социального.
Наши владельцы компаний (в подавляющем большинстве) не способны делегировать управленческие функции кому-либо, боятся открывать бизнес-информацию «посторонним» и искренне считают, что умеют управлять своим бизнесом (в т.ч. и технологической его частью) лучше всех.
В результате, вместо того, чтобы просто подписать контракт с профессионалами и получить результат за свои деньги, наши руководители бизнеса предпочитают вляпаться по полной программе в вещи, в которых ничего не понимают (например, в разработку софта).
Вы привели прекрасный пример. Во втором случае часто будет вкуснее, но всегда будет дороже. А плюс к этому — вся ответственность лежит внутри компании (т.е. все проверки СЭС будут ваши, а в случае отравления — отвечать будете вы).
Наши владельцы компаний (в подавляющем большинстве) не способны делегировать управленческие функции кому-либо, боятся открывать бизнес-информацию «посторонним» и искренне считают, что умеют управлять своим бизнесом (в т.ч. и технологической его частью) лучше всех.
В результате, вместо того, чтобы просто подписать контракт с профессионалами и получить результат за свои деньги, наши руководители бизнеса предпочитают вляпаться по полной программе в вещи, в которых ничего не понимают (например, в разработку софта).
Вы привели прекрасный пример. Во втором случае часто будет вкуснее, но всегда будет дороже. А плюс к этому — вся ответственность лежит внутри компании (т.е. все проверки СЭС будут ваши, а в случае отравления — отвечать будете вы).
суровая статистика говорит о провале в половине внедрений. Такчт не всё так однозначно. Не обязательно дороже или дешевле. От многих факторов зависит.
Я такой статистики не понимаю. Вы хотите сказать, что в другой половине случаев внедрение было успешным?!!! Да ладно!
Еще раз: успешных внедрений практически не бывает (я не слышал ни об одном, по крайней мере), но при этом хоть какой-то результат есть почти в 100% случаев (по одной простой причине — внедренцы никогда не подписываются на результат, т.е. деньги они получают практически в любом случае по план-графику, а заказчикам остается либо их списать, либо пользоваться тем, что получилось).
Так вот, достижение такого же результата инхауз разработкой обошлось бы дороже просто всегда (если вообще такой же результат был бы в принципе достижим, что для инхауз разработки не всегда гарантировано).
Еще раз: успешных внедрений практически не бывает (я не слышал ни об одном, по крайней мере), но при этом хоть какой-то результат есть почти в 100% случаев (по одной простой причине — внедренцы никогда не подписываются на результат, т.е. деньги они получают практически в любом случае по план-графику, а заказчикам остается либо их списать, либо пользоваться тем, что получилось).
Так вот, достижение такого же результата инхауз разработкой обошлось бы дороже просто всегда (если вообще такой же результат был бы в принципе достижим, что для инхауз разработки не всегда гарантировано).
>В результате, вместо того, чтобы просто подписать контракт с профессионалами и получить результат за свои деньги…
Фишка в том, что в нашей стране ни кто и ни за что не отвечает. И отдав денег какому-то типа профессионалу, нет никаких гарантий, что вы получите за свои деньги результат. Раздолбайство процветает на всех уровнях. Поэтому многие согласны переплачивать своим разработчикам, рассчитывая таким образом их контролировать и получить результат…
Вопрос конечно спорный, но из своего многолетнего опыта я предпочту инхауз разработку… современные технологии позволяют очень быстро получить результат. Ну или в крайнем случае основывать разработку на какой либо открытой системе.
Фишка в том, что в нашей стране ни кто и ни за что не отвечает. И отдав денег какому-то типа профессионалу, нет никаких гарантий, что вы получите за свои деньги результат. Раздолбайство процветает на всех уровнях. Поэтому многие согласны переплачивать своим разработчикам, рассчитывая таким образом их контролировать и получить результат…
Вопрос конечно спорный, но из своего многолетнего опыта я предпочту инхауз разработку… современные технологии позволяют очень быстро получить результат. Ну или в крайнем случае основывать разработку на какой либо открытой системе.
Т.е. если выбирать между официальным договором с каким-нибудь БиТ, где указана ответственность сторон, четкий план-график и т.п., и набором неизвестно каких (потому что компания непрофильная и оценить их объективно тупо некому) программистов в штат, Вы выберете второй вариант? Ну-ну.
Вы говорите как пиарщик… почему вы всегда утверждаете, что оценивать будет «непрофильная компания» ??
Оценивают всегда не компании, а конкретные люди… во всех крупных компаниях что я видел, есть технический директор, который вполне может нанять одного единственного грамотного руководителя отдела разработки… а дальше дело техники. Этот руководитель уже сможет грамотно подобрать разработчиков и сделать продукт.
Все делают конкретные люди, а не теоретические «непрофильные фирмы»
Оценивают всегда не компании, а конкретные люди… во всех крупных компаниях что я видел, есть технический директор, который вполне может нанять одного единственного грамотного руководителя отдела разработки… а дальше дело техники. Этот руководитель уже сможет грамотно подобрать разработчиков и сделать продукт.
Все делают конкретные люди, а не теоретические «непрофильные фирмы»
Я так утверждаю, потому что это так и есть. Ну, типа, некоторый опыт ИТ-директорства в обычных торговых компаниях (помимо опыта руководства разработкой софта) мне это позволяет утверждать, я надеюсь.
Технический директор в компании, продающей товары народного потребления? Уже весело, да. А еще и способный при этом отличить грамотного руководителя разработки от неграмотного, да еще и выбрать при этом технологию разработки (кого нанимать-то — дельфиста, сиплюсплюсника, сишарпера, одинэксника и т.п.?)…
Технический директор в компании, продающей товары народного потребления? Уже весело, да. А еще и способный при этом отличить грамотного руководителя разработки от неграмотного, да еще и выбрать при этом технологию разработки (кого нанимать-то — дельфиста, сиплюсплюсника, сишарпера, одинэксника и т.п.?)…
Вы опять передергиваете…
Если вы будучи ИТ-директором были не в состоянии разбираться в людях и нанимать хороших спецов, то это не означает, что все такие.
Такие проблемы есть только у совсем маленьких контор, которым не нужно внедрение ERP в принципе. Типовая 1С за 9т.р. перекрывает их требования с головой.
А в любой боле-менее крупной компании есть необходимость в нормальном ИТ деркторе.
И если они не могут такого нанять, то конечно у них будут проблемы. Проблемы будут даже с внешними внедряльщиками, ибо он и среди них не сможет подобрать нормального.
Как пример могу привести Calculate-Linux. Фирма занимается толи окнами, толи дверьми, непомню точно. Их ИТ отдел создал для себя линукс дистрибутив, а потом выложил его для всех. И это офигенно удобный и стабильный дистрибудтив для компаний.
Вот вам и непрофильная фирма…
Все и везде решают конкретные люди а не какие-то «профильные компании». И не факт, что в профильной компании работают грамотные спецы…
Если вы будучи ИТ-директором были не в состоянии разбираться в людях и нанимать хороших спецов, то это не означает, что все такие.
Такие проблемы есть только у совсем маленьких контор, которым не нужно внедрение ERP в принципе. Типовая 1С за 9т.р. перекрывает их требования с головой.
А в любой боле-менее крупной компании есть необходимость в нормальном ИТ деркторе.
И если они не могут такого нанять, то конечно у них будут проблемы. Проблемы будут даже с внешними внедряльщиками, ибо он и среди них не сможет подобрать нормального.
Как пример могу привести Calculate-Linux. Фирма занимается толи окнами, толи дверьми, непомню точно. Их ИТ отдел создал для себя линукс дистрибутив, а потом выложил его для всех. И это офигенно удобный и стабильный дистрибудтив для компаний.
Вот вам и непрофильная фирма…
Все и везде решают конкретные люди а не какие-то «профильные компании». И не факт, что в профильной компании работают грамотные спецы…
Никакой ответственности со стороны сторонней организации нет. Вы хоть раз слышали, чтобы с кого-нибудь стрясли бабло за провал автоматизации? Нет, ибо документально доказать ничего не-воз-мож-но. По документам и отчётам всё будет шоколадно, а на практике — никак.
Вы ошибаетесь.
Прежде всего, главная ответственность подрядчика заключается не в «вернуть деньги», а в «не получить деньги». Каждый договор внедрения имеет план-график работ и платежей. Нормальный заказчик разбивает процесс на достаточно короткие этапы (разумный минимум — две недели). Платится аванс за две недели, потом (если заказчик удовлетворен и подписан акт) платится остаток за эти две недели и аванс за следующие. Таким образом и заказчик, и подрядчик рискуют деньгами максимум за две недели (заказчик — авансом, подрядчик — остальным платежом).
В случае инхауз разработки ситуация, мягко говоря, иная.
Прежде всего, главная ответственность подрядчика заключается не в «вернуть деньги», а в «не получить деньги». Каждый договор внедрения имеет план-график работ и платежей. Нормальный заказчик разбивает процесс на достаточно короткие этапы (разумный минимум — две недели). Платится аванс за две недели, потом (если заказчик удовлетворен и подписан акт) платится остаток за эти две недели и аванс за следующие. Таким образом и заказчик, и подрядчик рискуют деньгами максимум за две недели (заказчик — авансом, подрядчик — остальным платежом).
В случае инхауз разработки ситуация, мягко говоря, иная.
Все вы так говорите.
В реальности же выглядит так:
— Ну что вы хотите за две недели! Результат далеко не сразу видно! Бла-бла-бла.
В итоге через год ни денег, ни результата.
В реальности же выглядит так:
— Ну что вы хотите за две недели! Результат далеко не сразу видно! Бла-бла-бла.
В итоге через год ни денег, ни результата.
Кто «мы»? Я вообще-то чаще на стороне заказчика выступал. И не подписывать акт — это очень просто, поверьте. Гораздо проще, чем подписать. Причем способов давления у подрядчика на заказчика нет просто никаких, если договор был составлен нормальный, а не подмахнули не глядя первый же вариант, подсунутый подрядчиком.
Да, подрядчики с удовольствием «разводят лохов», кто спорит? Так просто не надо быть лохом, вот и все.
Да, подрядчики с удовольствием «разводят лохов», кто спорит? Так просто не надо быть лохом, вот и все.
В сферической реальности в вакууме всё действительно просто. Но в суровой реальности всё ровно так, как я описал.
Главная проблема в том, что если на стороне заказчика нет грамотно технического специалиста, способного оценить проделанную работу по «внедрению», подписание таких актов превращается в пустую формальность. А если такой специалист есть, то фирма сама может написать себе под процессы систему.
Под «вы» я понимаю пиарщиков ерпни всякой, пиарщики наглые, многословные, легко способны заболтать руководителей, чтобы слупить с них денег. А потом ещё и на поддержку подсадить.
Главная проблема в том, что если на стороне заказчика нет грамотно технического специалиста, способного оценить проделанную работу по «внедрению», подписание таких актов превращается в пустую формальность. А если такой специалист есть, то фирма сама может написать себе под процессы систему.
Под «вы» я понимаю пиарщиков ерпни всякой, пиарщики наглые, многословные, легко способны заболтать руководителей, чтобы слупить с них денег. А потом ещё и на поддержку подсадить.
Вы сейчас, очевидно, о чем-то личном пишете с таким надрывом.
Если «на стороне заказчика нет грамотно технического специалиста, способного оценить проделанную работу» — то, конечно, инхауз разработка будет успешной на 100%, ага. Явное, так сказать, преимущество перед аутсорсом, офигеть.
Еще раз попробую: вы совершенно напрасно меня причисляете к продавцам ERP. Я, наоборот, в случае ERP был всегда на другой стороне прилавка — покупателем, т.е. заказчиком. Так вот, с точки зрения заказчика, который живет не разработкой софта, нанимать команду программистов, чтобы они тебе написали нечто вроде 1С: УПП (да еще и на дельфях и оракле, как где-то в этих каментах мелькало) — это просто ад кромешный.
Никто не отрицает, что автоматизация на аутсорсе — зло. Просто это зло куда меньшее, чем инхауз разработка для непрофильных компаний.
Если «на стороне заказчика нет грамотно технического специалиста, способного оценить проделанную работу» — то, конечно, инхауз разработка будет успешной на 100%, ага. Явное, так сказать, преимущество перед аутсорсом, офигеть.
Еще раз попробую: вы совершенно напрасно меня причисляете к продавцам ERP. Я, наоборот, в случае ERP был всегда на другой стороне прилавка — покупателем, т.е. заказчиком. Так вот, с точки зрения заказчика, который живет не разработкой софта, нанимать команду программистов, чтобы они тебе написали нечто вроде 1С: УПП (да еще и на дельфях и оракле, как где-то в этих каментах мелькало) — это просто ад кромешный.
Никто не отрицает, что автоматизация на аутсорсе — зло. Просто это зло куда меньшее, чем инхауз разработка для непрофильных компаний.
Это всё отлично, но где хотя бы одно успешное внедрение в немелкую компанию? Не формальное, а чтобы прям совсем круто стало. Нет такого. Никто и нигде такого не встречал.
Задача ерпни — выбить бабло по максимуму, знающие люди отлично понимают, что заявленных золотых гор они не получат и готовы получить говносистему, лишь бы хоть как-то работало.
В непрофильной компании МОЖНО сделать отличную систему для себя. Главное иметь нескольких людей:
1. Понимающего бизнес-процессы данной компании аналитика из штата компании.
2. Руководителя-профессионала группы программистов.
3. Умного руководителя, понимающего, что от внешних внедренцев они никогда не получат того, что они обещают. А получа, скорее всего, навязанного «консультанта» с дикой зарплатой.
Но поскольку длительного стратегического планирования часто не бывает, возникает соблазн «сделать быстро» за счёт внешней системы. Вот только потери на этом будут гигантские.
А непрофильные компании отлично себе разрабатывают свои системы, иногда отдают их на аутсорс, но не ерпшникам, а просто программистам, а себе нанимают максимум бизнес-аналитика, который занимается анализом и корректировкой бизнес-процессов.
Ну, и как завершение. Если в фирме ИТ-директор кретин, то ничего хорошего из этого не выйдет в любом случае. А если ИТ-директор умный, и все начальники умные и практичные, то в такой компании можно воспитать ит-отдел из пары человек, который будет неспешно, но организованно пилить собственную бизнес-систему под свои родные нужды.
Задача ерпни — выбить бабло по максимуму, знающие люди отлично понимают, что заявленных золотых гор они не получат и готовы получить говносистему, лишь бы хоть как-то работало.
В непрофильной компании МОЖНО сделать отличную систему для себя. Главное иметь нескольких людей:
1. Понимающего бизнес-процессы данной компании аналитика из штата компании.
2. Руководителя-профессионала группы программистов.
3. Умного руководителя, понимающего, что от внешних внедренцев они никогда не получат того, что они обещают. А получа, скорее всего, навязанного «консультанта» с дикой зарплатой.
Но поскольку длительного стратегического планирования часто не бывает, возникает соблазн «сделать быстро» за счёт внешней системы. Вот только потери на этом будут гигантские.
А непрофильные компании отлично себе разрабатывают свои системы, иногда отдают их на аутсорс, но не ерпшникам, а просто программистам, а себе нанимают максимум бизнес-аналитика, который занимается анализом и корректировкой бизнес-процессов.
Ну, и как завершение. Если в фирме ИТ-директор кретин, то ничего хорошего из этого не выйдет в любом случае. А если ИТ-директор умный, и все начальники умные и практичные, то в такой компании можно воспитать ит-отдел из пары человек, который будет неспешно, но организованно пилить собственную бизнес-систему под свои родные нужды.
Вы прочитайте, что я здесь пишу. Да, успешных внедрений нет, это факт. При этом результатами практически всех внедрений компании пользуются и деньги зарабатывают по своей основной теме.
Вы сейчас буквально следующее пишете: на каждом рынке есть десятки (на некоторых рынках — и сотни) средних конкурирующих компаний, и каждая должна нанимать грамотных программистов, менеджеров и аналитиков в свой штат, чтобы они специально для нее сделали уникальную ERP систему.
Ну что же, тоже подход, да. Программисты без работы точно не останутся в этом случае. Просто лично я считаю подобный подход массовой (и крайне дорогостоящей) работой на мусорную корзину.
Вы сейчас буквально следующее пишете: на каждом рынке есть десятки (на некоторых рынках — и сотни) средних конкурирующих компаний, и каждая должна нанимать грамотных программистов, менеджеров и аналитиков в свой штат, чтобы они специально для нее сделали уникальную ERP систему.
Ну что же, тоже подход, да. Программисты без работы точно не останутся в этом случае. Просто лично я считаю подобный подход массовой (и крайне дорогостоящей) работой на мусорную корзину.
Ну так ой. У вас как у руководителя два варианта:
1. Подсесть на иглу ERP-систему, которая НЕ выполняет то, чего обещает. При этом высасывает кучу денег.
2. Организоваться и написать себе свою ERP-систему, которая будет работать идеально для своих бизнес-процессов.
П.2 выполнить очень сложно по причинам, которые я выше указывал (человеческий фактор+жадность). Поэтому остаётся п.1.
Это реальность, но я не считаю, что она хорошая и правильная. Это говно какое-то, простите.
1. Подсесть на иглу ERP-систему, которая НЕ выполняет то, чего обещает. При этом высасывает кучу денег.
2. Организоваться и написать себе свою ERP-систему, которая будет работать идеально для своих бизнес-процессов.
П.2 выполнить очень сложно по причинам, которые я выше указывал (человеческий фактор+жадность). Поэтому остаётся п.1.
Это реальность, но я не считаю, что она хорошая и правильная. Это говно какое-то, простите.
Консенсус почти.
Во втором пункте только надо добавить, что а) это наверняка выйдет дороже и дольше, чем внедрить готовую и б) далеко не факт, что удастся достичь состояния «будет работать идеально».
По выводам — ну да, «говно какое-то». Но по важности для бизнеса — это «говно» относительно незначительное. Единицы компаний разоряются из-за того, что у них ERP фиговая. Так что терпеть вполне можно.
Во втором пункте только надо добавить, что а) это наверняка выйдет дороже и дольше, чем внедрить готовую и б) далеко не факт, что удастся достичь состояния «будет работать идеально».
По выводам — ну да, «говно какое-то». Но по важности для бизнеса — это «говно» относительно незначительное. Единицы компаний разоряются из-за того, что у них ERP фиговая. Так что терпеть вполне можно.
Работал в крупной логистической компании. Новое руководство решило отказаться от самописной системы и перейти на коммерческую систему PSI WMS. Запустили внедрение. Программисты — кто уволился, кто работает на внедрении.
В результате количество доработок под запуск бизнес-процессов одного из самых крупных клиентов составило примерно два человеко-года — ну не умеет немецкая система работать со специфическими российскими реалиями типа ГТД. Примерная стоимость человеко-дня, выдвинутая нам немцами — чуть меньше килоевро.
Опаньки…
В результате количество доработок под запуск бизнес-процессов одного из самых крупных клиентов составило примерно два человеко-года — ну не умеет немецкая система работать со специфическими российскими реалиями типа ГТД. Примерная стоимость человеко-дня, выдвинутая нам немцами — чуть меньше килоевро.
Опаньки…
Опять же, попрошу для сравнения с 440К евро (два человеко-года немцев) привести для сравнения бюджет инхауз разработки.
Да, затраты на внедрение впечатляют, потому что это контракт, у которого видна стоимость «итого». А внутренние затраты — они постоянные, размазаны по времени и никто просто не догадывается обычно, во сколько инхауз-разработчики обходятся компании в результате.
Да, затраты на внедрение впечатляют, потому что это контракт, у которого видна стоимость «итого». А внутренние затраты — они постоянные, размазаны по времени и никто просто не догадывается обычно, во сколько инхауз-разработчики обходятся компании в результате.
Отдел состоял из 18 программистов со средней зарплатой в районе 70 тысяч (средняя температура по больнице, дельфисты получали 50-60, ораклисты — за 100). Получается, за два года на нас ушло бы ~720К евро.
Вы возможно не поняли: немцам надо два года делать то, что УЖЕ БЫЛО в старой системе. А под посадку новых нестандартных клиентов придется дополнительно тратиться по тому же прайсу: 1000 евро в день.
Причем если мы реализовывали фичи в среднем за три дня — то у немцев как правило фигурируют цифры порядка двадцати. За простой транспортных средств того же «одного из самых крупных клиентов» компанией выплачиваются компенсации порядка 50К евро — было озвучено на одном из обсуждений количества доработок.
Вы возможно не поняли: немцам надо два года делать то, что УЖЕ БЫЛО в старой системе. А под посадку новых нестандартных клиентов придется дополнительно тратиться по тому же прайсу: 1000 евро в день.
Причем если мы реализовывали фичи в среднем за три дня — то у немцев как правило фигурируют цифры порядка двадцати. За простой транспортных средств того же «одного из самых крупных клиентов» компанией выплачиваются компенсации порядка 50К евро — было озвучено на одном из обсуждений количества доработок.
У вас, похоже, все еще хуже, чем в среднем по стране. Бюджет на инхауз разработчиков мегабакс в год — это офигеть, если честно. Вы понимаете, что за три мегабакса (три ваших года) можно почти любой аналогичный покупной софт адаптировать с гарантией, поддержкой, баккара и актрисками?
Естественно офигеть! Потому-что если не фигеть а считать — получается где-то 350К.
70000 / 43 * 12 * 18 = 351627
70000 / 43 * 12 * 18 = 351627
Вы еще на 1.82 не забудьте умножить, пожалуйста (и это только налоги, а есть еще такая забавная вещь, как накладные расходы).
1.82???
НДФЛ -13%
ЕСН в Пенсионный фонд, зачисляемый в ФБ РФ — 14%
ЕСН в ФСС — 2,9%
ЕСН в ФФОМС — 1,1%
ЕСН в ТФОМС — 2%
Страховые взносы на страховую часть пенсии — 10%
Страховые взносы на накопительную часть пенсии — 4%
Соцстрах — 0,2%-1% в зависимости от деятельности компании
1.48 получается.
Где я не прав?
НДФЛ -13%
ЕСН в Пенсионный фонд, зачисляемый в ФБ РФ — 14%
ЕСН в ФСС — 2,9%
ЕСН в ФФОМС — 1,1%
ЕСН в ТФОМС — 2%
Страховые взносы на страховую часть пенсии — 10%
Страховые взносы на накопительную часть пенсии — 4%
Соцстрах — 0,2%-1% в зависимости от деятельности компании
1.48 получается.
Где я не прав?
Понятно, что вы, наверное, технический работник. Давайте открою Вам глаза.
100р на руки — значит ФОТ=100/(100-13)*100=115р.
34% страховых взносов, т.е. 114*1.34=154р ФОТ+взносы.
Чтобы заплатить 154р, компания должна продать товаров/услуг на 154р, заплатив с них при этом 18% НДС. Итого 154*1.18=182р.
Т.е. на каждые 100р, выплаченные вам на руки, приходится 82р, отданные вашим работодателем нашему государству.
При этом если покупать внедрение на стороне, то НДС идет к зачету, т.е. вычитается, а не прибавляется.
100р на руки — значит ФОТ=100/(100-13)*100=115р.
34% страховых взносов, т.е. 114*1.34=154р ФОТ+взносы.
Чтобы заплатить 154р, компания должна продать товаров/услуг на 154р, заплатив с них при этом 18% НДС. Итого 154*1.18=182р.
Т.е. на каждые 100р, выплаченные вам на руки, приходится 82р, отданные вашим работодателем нашему государству.
При этом если покупать внедрение на стороне, то НДС идет к зачету, т.е. вычитается, а не прибавляется.
Ну, фактически НДС добавляется к желаемой цене товара, и получается, что «платит» его покупатель, но ОК, вы правы.
Не забывайте еще про российские реалии. Во многих компаниях будет не 50 т.р. * 1.82, а 5 т.р. * 1.82 + 45 т.р. в конвертике. А вот подрядчику серым налом уже особо не заплатишь + надо выискивать средства из белой части бухгалтерии, чтобы сальдо было положительным хотя бы.
Вы удивитесь, но иногда белый безнал для подрядчика именно в российских реалиях найти проще, чем черный нал для программистов (кстати, какого же уровня будут эти программисты, если они соглашаются на такие условия?).
Серые зарплаты сейчас очень и очень стремная вещь. Обычно платится просто 10% оклад плюс 90% премия, но это просто чтобы увольнять было дешево, а налоги-то с них платятся все.
Серые зарплаты сейчас очень и очень стремная вещь. Обычно платится просто 10% оклад плюс 90% премия, но это просто чтобы увольнять было дешево, а налоги-то с них платятся все.
Не знаю насчет стремной, я получаю на 100% черную (т.е. я даже и не устроен там) з/п из России в Китае, достаточно приличную, доходы от бизнеса через оффшоры, мне даром не нужна ипотека и кредиты, в пенсию от государства я не верю, так что все ок. Многие знакомые работают так же.
Это так. А многие еще грабежом и разбоем живут, чего уж…
Вы понимаете, что человек, переводящий Вам черный нал из России в Китай, ходит под уголовной статьей? И Вы считаете эту ситуацию нормальной?
Вы понимаете, что человек, переводящий Вам черный нал из России в Китай, ходит под уголовной статьей? И Вы считаете эту ситуацию нормальной?
Скажем так, мое понятие «нормальности» тут нивелируется тем, что я бы получал в 2 раза меньше, отдавая деньги туда, где я от них не получаю и не получу никогда никакой пользы. Просто здравый смысл.
Насчет статей — мне светит административное и штраф (за неуведомление об открытии счета), отправителю на таких объемах не светит ничего, потому что расходы на раскрытие таких мелких нарушений многократно больше государственной прибыли от этого самого раскрытия. Посмотрите на это с точки зрения налогов как государственного бизнеса. Я же не Ходорковский, миллиардов у меня нет и от политики далек.
Насчет статей — мне светит административное и штраф (за неуведомление об открытии счета), отправителю на таких объемах не светит ничего, потому что расходы на раскрытие таких мелких нарушений многократно больше государственной прибыли от этого самого раскрытия. Посмотрите на это с точки зрения налогов как государственного бизнеса. Я же не Ходорковский, миллиардов у меня нет и от политики далек.
Вы сейчас ярко зажгли, если честно.
Абзац первый: «Я не плачу налоги, потому что платить их — глупость».
Абзац второй: «Можно смело нарушать законы, если по чуть-чуть».
Я даже не буду ничего говорить про моральный аспект Ваших утверждений. Но вот чисто с практической точки зрения — я бы на таких ставках играть не сел. Вероятность, конечно, небольшая. Только вот матожидание зашкаливает.
Абзац первый: «Я не плачу налоги, потому что платить их — глупость».
Абзац второй: «Можно смело нарушать законы, если по чуть-чуть».
Я даже не буду ничего говорить про моральный аспект Ваших утверждений. Но вот чисто с практической точки зрения — я бы на таких ставках играть не сел. Вероятность, конечно, небольшая. Только вот матожидание зашкаливает.
Да хватит вам уже заливать про размазанные деньги… Ваши «итого» в контракте такая же космическая чушь… или вы хотите сказать, что после внедрения фирма будет счастливо жить с новым софтом до конца дней своих? И ни каких доработок не понадобиться? А вы задумывались почему софт пишется годами? В нашей стране не понос — так золотуха. Очень много всего меняется и это надо отражать в софте. Плюс фирма растет и развивается. Соответственно и требования меняются. Фактически в динамично развивающейся фирме разработка такого софта никогда не закончится.
Это у Вас какие-то эмоции странные поперли. Что значит «заливать»? Я где-то соврал в процессе дискуссии?
Конечно же после внедрения затраты на ERP не заканчиваются. Только если система «внешняя», то компания платит тогда, когда ей изменения понадобились (и есть возможность поторговаться), а если «внутренняя» — то просто 1 и 15 числа каждого месяца в соответствии со штатным расписанием.
Конечно же после внедрения затраты на ERP не заканчиваются. Только если система «внешняя», то компания платит тогда, когда ей изменения понадобились (и есть возможность поторговаться), а если «внутренняя» — то просто 1 и 15 числа каждого месяца в соответствии со штатным расписанием.
Опять вы как пиарщик говорите…
>Только если система «внешняя», то компания платит тогда, когда ей изменения понадобились
При этом вы скромно умалчиваете, что такие изменения нужны будут постоянно…
>Только если система «внешняя», то компания платит тогда, когда ей изменения понадобились
При этом вы скромно умалчиваете, что такие изменения нужны будут постоянно…
Я вообще-то профессиональный разработчик софта. Но вы можете меня считать пиарщиком — для меня это лестная оценка моих усилий говорить доступно.
Слово «постоянно» — оно очень сильное. Как, опять же, профессиональный разработчик софта, я хорошо знаю, что такое «версионность», и чем подход с версиями выгоднее подхода с непрерывным внесением изменений в работающий продукт.
Слово «постоянно» — оно очень сильное. Как, опять же, профессиональный разработчик софта, я хорошо знаю, что такое «версионность», и чем подход с версиями выгоднее подхода с непрерывным внесением изменений в работающий продукт.
да все так говорят. И про версионность, и про процессную ориентированность, и своим исо9000 тычут. Как внедряльщики, так и те кто продвигают собственный ИТ внутри фирмы.
Все говорят, что люди дышат кислородом. Возможно, они правы?
речь про деньги а не про разговоры. Если бюджет большой то и внедряльщики и собственный ИТ сделют всё чтобы убедить руководство отдать этот бюджет именно им.
И обе стороны не всегда будут озвучивать честные и трезвые оценки сроков и затрат. Но как они будут петь хором! А какие красивые презенташки в пауерпоинте приташат!
По уму руководству лучше ни тех ни других не слушать а нанять консультанта со стороны для их оценки. Но это дополнительные траты.
И обе стороны не всегда будут озвучивать честные и трезвые оценки сроков и затрат. Но как они будут петь хором! А какие красивые презенташки в пауерпоинте приташат!
По уму руководству лучше ни тех ни других не слушать а нанять консультанта со стороны для их оценки. Но это дополнительные траты.
Это не так.
Будучи ИТ-директором, я всегда выступал за аутсорс программных разработок (хотя, поверьте, уж как это правильно делать я вполне в курсе).
Просто аутсорс разработка для непрофильных компаний выгоднее всем абсолютно. Вин-вин такой.
Будучи ИТ-директором, я всегда выступал за аутсорс программных разработок (хотя, поверьте, уж как это правильно делать я вполне в курсе).
Просто аутсорс разработка для непрофильных компаний выгоднее всем абсолютно. Вин-вин такой.
это всего лишь ваша личная оценка.
Конечно в идеальном случае в вакууме отдать непрофильное направление на аутсорс должно быть выгодно.
И в реальности в ряде случаев так. В других случаях иначе. На больших предприятиях не может быть простых решений и безапелляционных мнений.
Например возьмём очень крупную организацию типа сбербанка или боинга — они не пустят к себе чужих внедряльщиков просто потому что никто с их объёмами и спецификой не справится. Будут покупать какие-то решения но интегрировать будут сами.
Или где-то требуется кастомизация чуть сложнее обычной — всё, поддержка будет дороже содержания своего штата програмастов.
Конечно в идеальном случае в вакууме отдать непрофильное направление на аутсорс должно быть выгодно.
И в реальности в ряде случаев так. В других случаях иначе. На больших предприятиях не может быть простых решений и безапелляционных мнений.
Например возьмём очень крупную организацию типа сбербанка или боинга — они не пустят к себе чужих внедряльщиков просто потому что никто с их объёмами и спецификой не справится. Будут покупать какие-то решения но интегрировать будут сами.
Или где-то требуется кастомизация чуть сложнее обычной — всё, поддержка будет дороже содержания своего штата програмастов.
Я вас ни кем не считаю, а просто утверждаю, что вы говорите как пиарщик.
Выдергиваете фразы из контекста, передергиваете понятия, однобоко рассматриваете факты и т.д.
Априори утверждаете, что инхауз по любому хуже внешних внедряльщиков…
Все ваши фразы как рекламный плакат. Вы наверно привыкли убеждать других, что им необходимы ваши услуги.
Но у меня на такие фразы стойкий иммунитет…
Опять же. Кто вам сказал, что внутренняя разработка ведется абы как?
Почему внутренняя разработка не может вестись «версионно», по плану и прочими методиками?
Я больше 10 лет разрабатывал и внедрял различные системы на предприятиях. Был и со стороны заказчиков и со стороны внешних внедряльцев, при чем не только как разработчик, но и как ИТ-директор и как ПМ. Кухню эту знаю отлично.
Так что, все ваши аргументы (ну кроме финансовых расчетов — они выглядят логично), чистый пиар, имеющий очень слабенькую фактическую основу.
Выдергиваете фразы из контекста, передергиваете понятия, однобоко рассматриваете факты и т.д.
Априори утверждаете, что инхауз по любому хуже внешних внедряльщиков…
Все ваши фразы как рекламный плакат. Вы наверно привыкли убеждать других, что им необходимы ваши услуги.
Но у меня на такие фразы стойкий иммунитет…
Опять же. Кто вам сказал, что внутренняя разработка ведется абы как?
Почему внутренняя разработка не может вестись «версионно», по плану и прочими методиками?
Я больше 10 лет разрабатывал и внедрял различные системы на предприятиях. Был и со стороны заказчиков и со стороны внешних внедряльцев, при чем не только как разработчик, но и как ИТ-директор и как ПМ. Кухню эту знаю отлично.
Так что, все ваши аргументы (ну кроме финансовых расчетов — они выглядят логично), чистый пиар, имеющий очень слабенькую фактическую основу.
Спасибо еще раз за лестную оценку.
«Априори утверждаете, что инхауз по любому хуже внешних внедряльщиков…» — не хуже, а дольше и дороже. Это разные вещи.
«Кто вам сказал, что внутренняя разработка ведется абы как?» — я это просто наблюдал неоднократно, а вот обратного не видел ни разу.
«Почему внутренняя разработка не может вестись «версионно», по плану и прочими методиками?» — потому что для этого нет никаких предпосылок в компании, которая зарабатывает не разработкой софта, т.е. во всем этом ничего не понимает.
«Так что, все ваши аргументы (ну кроме финансовых расчетов — они выглядят логично), чистый пиар, имеющий очень слабенькую фактическую основу.» — про «фактическую основу» Вы меня прям срезали, да.
«Априори утверждаете, что инхауз по любому хуже внешних внедряльщиков…» — не хуже, а дольше и дороже. Это разные вещи.
«Кто вам сказал, что внутренняя разработка ведется абы как?» — я это просто наблюдал неоднократно, а вот обратного не видел ни разу.
«Почему внутренняя разработка не может вестись «версионно», по плану и прочими методиками?» — потому что для этого нет никаких предпосылок в компании, которая зарабатывает не разработкой софта, т.е. во всем этом ничего не понимает.
«Так что, все ваши аргументы (ну кроме финансовых расчетов — они выглядят логично), чистый пиар, имеющий очень слабенькую фактическую основу.» — про «фактическую основу» Вы меня прям срезали, да.
Про «фактическую основу» я имел ввиду ваше основное и очень спорное и слабенькое утверждение на основе которого вы строите свои аргументы.
Оно звучит примерно так «В компании продающей пончики, разработкой софта будут заниматься не профильные люди: повара, продавцы, кладовщики и т.д.»
А это, извините, выглядит смешно.
В такой компании есть люди профи в продаже пончиков, производстве пончиков, есть водители, бухгалтера и прочие люди… и далеко не для всех них сами пончики являются проф деятельностью…
Так почему среди них не может быть хороших программистов и прочих людей необходимых для разработки софта?
Опять же ваши утверждения на счет того что директор такой конторы просто не сможет найти хорошего руководителя ИТ т.к. не разбирается в этом — тоже смешны.
А как же себе ищут глав бухов и других спецов? Или у нас все директора такие спецы в бухгалтерии и налогах?
Оно звучит примерно так «В компании продающей пончики, разработкой софта будут заниматься не профильные люди: повара, продавцы, кладовщики и т.д.»
А это, извините, выглядит смешно.
В такой компании есть люди профи в продаже пончиков, производстве пончиков, есть водители, бухгалтера и прочие люди… и далеко не для всех них сами пончики являются проф деятельностью…
Так почему среди них не может быть хороших программистов и прочих людей необходимых для разработки софта?
Опять же ваши утверждения на счет того что директор такой конторы просто не сможет найти хорошего руководителя ИТ т.к. не разбирается в этом — тоже смешны.
А как же себе ищут глав бухов и других спецов? Или у нас все директора такие спецы в бухгалтерии и налогах?
>> если система «внешняя», то компания платит тогда, когда ей изменения понадобились
а результат получает тогда, когда он уже не нужен?
а результат получает тогда, когда он уже не нужен?
Ох, как же я вас понимаю. Работаю в компании с очень похожей ситуацией. Есть самописная система, поддерживающая основные бизнес-процессы, есть купленная система документооборота, и еще одна купленная BPM система.Путаницы, дублирующего функционала, пользователей, которые саботируют любые радикальные изменения — хоть лопатой греби.
Просто у этой ERP никогда не было красивого названия. В этом вся проблема.
свой ERP — прикольно :)
пускай купят готовые финансовые модули и интерфейсами свяжут со своей разработкой логистики — через там ETL какой-нить, не?
пускай купят готовые финансовые модули и интерфейсами свяжут со своей разработкой логистики — через там ETL какой-нить, не?
Ребята не могут дописать партионный учёт? Не верю. Скорее всего, бизнес не может родить приемлемого решения того, как этот партионный учёт приделать организационно, не увеличив при этом во сто крат издержки. А поле в табличку заALTER'ить — это вообще не проблема.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десять гребаных лет на разработку ERP