Как мы должны оценивать «Создать или купить» для ERP-системы?

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

Вот шаги, которые я бы использовал:

Создайте критерии для каждой категории пользы, стоимости и риска; Проведение семинаров с соответствующими техническими и деловыми МСП; Итерация баллов; Проведите семинары, чтобы проверить, какие из них оказались самыми высокими.

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

Чанчо, добро пожаловать в PMSE! Рекомендуем вам ознакомиться с Руководством по Своду знаний по управлению проектами, 5-е издание, раздел 12, озаглавленный «Управление закупками проекта», и, в частности, раздел 12.1.2.1, озаглавленный «Анализ по принципу «производи или покупай».

У вас есть несколько решений для рассмотрения, а не только «Создать или купить».

Что касается покупки, вам нужно будет рассмотреть несколько различных вариантов покупки;

1. Анализ пробелов ваших процессов и бизнес-целей в сравнении с рядом продуктов ERP (все они разные, естественно подходят для разных вертикалей)
2. Модели доставки (итеративные или крупномасштабные)
3. Комбинации небольших лучших в своем классе продуктов, а не только одна ERP
4. Скрытые расходы, такие как затраты на внедрение, настройку, управление изменениями и текущие контракты на техническое обслуживание и поддержку.

Что касается Build, вам нужно будет рассмотреть несколько различных вариантов решения;

1. Выбор платформы/технологии/UX (облако, локальный, толстый клиент, веб, мобильный или их комбинация)
2. План выпуска (краткосрочный итеративный или масштабный) и разная скорость окупаемости инвестиций, которая обеспечивает

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

В итоге вы получите сводку анализа пробелов выбора продукта или разработки, сопоставленную с процессами (представьте себе большую электронную таблицу). Затем вам нужно будет оценить размер и стоимость устранения пробелов, что обычно требует тесного взаимодействия с вами поставщиков и компаний-разработчиков. Если какое-либо решение подходит менее чем на 70%, то его, вероятно, следует немедленно выбросить.

В итоге я считаю, что ни одно ERP-решение не удовлетворит ваши потребности из коробки. Я делаю это в течение 25 лет, и это ВСЕГДА так.

Итак... Gap-анализ - это ключ, и ожидайте, что у вас будет много вариантов выбора.

Удачи!

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

Конечно, важны обычные вопросы стоимость/ROI и скорость/точность. Но вы можете захотеть сделать более активное планирование рисков. Для этого я использую то, что HBR любит называть «pre-mortem».

Исследование, проведенное в 1989 г. Деборой Дж. Митчелл из Уортонской школы; Джей Руссо из Корнелла; и Нэнси Пеннингтон из Университета Колорадо обнаружили, что перспективное ретроспективное представление о том, что событие уже произошло, увеличивает способность правильно определять причины будущих результатов на 30%.

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

Подробнее об этом можно прочитать здесь: http://hbr.org/2007/09/performing-a-project-premortem

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

Плюсы вендорного решения:

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

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

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

Почти все уважающие себя ERP (и другие системы бизнес-администрирования) имеют возможность связываться с другими программами. Это почти всегда результат сотрудничества между компаниями: узнайте у вашей нынешней компании-разработчика программного обеспечения, какие системы совместимы и используются другими их пользователями. Это также иллюстрирует недостаток создания собственной системы: вам придется обойти некоторые части существующего программного обеспечения, если вы хотите, чтобы ваша новая система работала вместе с вашим существующим пакетом. (Раньше я работал с дампами данных fe, но я бы никому не рекомендовал!)

Я бы порекомендовал всю систему ERP только в том случае, если вы планируете внедрить ее во всей (производственной) компании. Я бы искал индивидуальную систему, если вам нужно что-то очень простое, иначе преимущества поддержки со стороны компании-разработчика программного обеспечения могут перевесить недостатки.