Надо стараться придерживаться трех простых правил, если вы хотите успешного внедрения.
Как это не странно, но именно разработка программного обеспечения — самое слабое место ERP-проектов. Какое бы красивое ТЗ ты не написал, ты никогда заранее не знаешь, будет это работать в реальной жизни или нет. Хорошие программы пишутся не с первого раза. Чем больше в проекте разработки, тем выше риски неудачи. Разработка ПО — это как создание дизайна. Вроде обо всем договорился, а когда получил результат — понимаешь, что не то. Разумеется есть только один способ снизить объем разработки — взять продукт, где уже по максимуму разработано и работает то, что тебе нужно.
Разработка требует отладки. Это значит, что после разработки могут быть проблемы при запуске системы (что-то не работает, что-то работает не так, про что-то вообще забыли и т.д.). Этот процесс снижает уровень лояльности пользователей, который потом поднять будет крайне сложно. Поэтому внедрять нужно начинать с какого-то базового, готового, железобетонно работающего, проверенного функционала, не требующего никаких разработок. Поставил — работает.
Чем больше сотрудников вовлечены в проект, тем больше шансов, что все будет хорошо. Если в проекте кто-то крутится, как белка в колесе, а остальные, ковыряясь палочкой в зубах, наблюдают за этим увлекательным аттракционом, то результата не будет. Впрочем это правило относится не только к ERP-системам, но и ко всем остальным масштабным проектам.
Проект должен дать быстрые и конкретные практические результаты. Какую-то часть системы надо запустить как можно быстрее. Какую — это вам решать с консультантом. Если проект длится год и никто не использует систему, то все привыкают к тому, что ERP-система в вашей компании для того и нужна, чтобы ее не использовать. Все просто привыкают к ситуации и не хотят ее менять. Запал, который был вначале начинает угасать. Стартовать систему нужно тогда, когда есть запал и желание, а не через год.
Минимум разработки
Как это не странно, но именно разработка программного обеспечения — самое слабое место ERP-проектов. Какое бы красивое ТЗ ты не написал, ты никогда заранее не знаешь, будет это работать в реальной жизни или нет. Хорошие программы пишутся не с первого раза. Чем больше в проекте разработки, тем выше риски неудачи. Разработка ПО — это как создание дизайна. Вроде обо всем договорился, а когда получил результат — понимаешь, что не то. Разумеется есть только один способ снизить объем разработки — взять продукт, где уже по максимуму разработано и работает то, что тебе нужно.
Разработка требует отладки. Это значит, что после разработки могут быть проблемы при запуске системы (что-то не работает, что-то работает не так, про что-то вообще забыли и т.д.). Этот процесс снижает уровень лояльности пользователей, который потом поднять будет крайне сложно. Поэтому внедрять нужно начинать с какого-то базового, готового, железобетонно работающего, проверенного функционала, не требующего никаких разработок. Поставил — работает.
Максимум вовлеченности сотрудников
Чем больше сотрудников вовлечены в проект, тем больше шансов, что все будет хорошо. Если в проекте кто-то крутится, как белка в колесе, а остальные, ковыряясь палочкой в зубах, наблюдают за этим увлекательным аттракционом, то результата не будет. Впрочем это правило относится не только к ERP-системам, но и ко всем остальным масштабным проектам.
Быстрые результаты
Проект должен дать быстрые и конкретные практические результаты. Какую-то часть системы надо запустить как можно быстрее. Какую — это вам решать с консультантом. Если проект длится год и никто не использует систему, то все привыкают к тому, что ERP-система в вашей компании для того и нужна, чтобы ее не использовать. Все просто привыкают к ситуации и не хотят ее менять. Запал, который был вначале начинает угасать. Стартовать систему нужно тогда, когда есть запал и желание, а не через год.
