Третья причина в том, что персонал компании обычно тестирует систему невнимательно. Специалисты из бизнеса смотрят на придуманные консультантами цифры через незнакомые интерфейсы и не готовы вникать в детали. Это может усугубляться высокой текущей занятостью и отсутствием ответственности за некачественное тестирование.
Оба предлагаемых способа непростые организационно и затратные. Однако это дешевле возможного простоя, и порой лучше потерять рубль сегодня, чем десять завтра. К тому же простой не сводится к недополученной прибыли — это, например, еще и отрицательное влияние на лояльность клиентов.
Первый способ используется довольно часто. Внедрение проводится не на пустом месте, обычно новая программа заменяет устаревшую или их семейство. Напрашивается очевидный путь тестирования — параллельный ввод данных в две системы одновременно. Чтобы специалисты по бизнесу от процесса не бегали, полезно закрепить этап приказом и инструментами его контроля. Важно, чтобы в систему вводилась полная информация за день. Если это невозможно, значит, система не готова или же специалисты не желают с нею работать.
Такой путь проверки можно применить и при запуске системы в опытную эксплуатацию. Тогда акт о начале промышленной эксплуатации будет связан с результатами сверки отчетов старой и новой систем. Это не значит, что результаты должны совпадать. В системах могут быть разные отчеты, разная точность и детализация учета. Однако полезно выявить причины несовпадения и оценить, насколько расхождение соответствует плановому. После начала промышленной эксплуатации старую систему можно отключать.
Второй способ более сложный. Он полезен, если объем обрабатываемых данных не позволяет одновременно вводить данные в обе системы. Следует полностью смоделировать день, а лучше несколько дней работы вашей компании. Например, так: устроить субботник для работников компании (рекомендую доплатить им за эту работу) и полностью выполнить ввод данных за один день прошедшей недели. В качестве образца для теста лучше выбрать день, наиболее загруженный в смысле объема данных. Специалисты ИТ будут контролировать все сложности, возникшие при работе системы, чтобы впоследствии от них избавиться. После исправления ошибок следует повторить эксперимент.
Очевидно, что такой способ тоже невозможен без приказа по фирме.
Если руководство устраняется от внедрения системы, то у внедренцев остается один рычаг воздействия на пользователя — создание для него специальных инструментов. При этом заметно падает эффективность использования приглашенных и дорогих ИТ-шников. Они вынуждены обеспечивать индивидуальными инструментами работников с низкой эффективностью труда.
Многие консультанты еще на этапе предпроекта уделяют слишком много внимания мнению пользователей о системе из-за невозможности консультаций с руководством компании. Отсюда — перекос проекта в сторону решения проблем пользователей. А разница в эффективности между системой, заточенной под решение задач пользователей, и системой, предназначенной для решения задач руководства компании, колоссальная.
Может сложиться впечатление, что руководитель компании одинок в своем желании внедрить ERP и противостоит остальному коллективу, однако есть сотрудники, которых можно и нужно мотивировать. Это ваши ИТ-специалисты, которые хотят оправдать свою высокую (вы же позаботились об этом?) зарплату и совсем не против получить в резюме запись об участии в успешном и сложном проекте. Заинтересуйте их, и у вас все получится!
Компания Koder Logic занимается разработкой и внедрением коммерческих учетных систем в торговых фирмах и промышленных предприятиях. Основное направление — внедрение системы Microsoft axapta. Ведущие специалисты компании работают с axapta с 2000 года. Также Koder Logic разрабатывает индивидуальные системы класса ERP.
Все специалисты компании имеют необходимые сертификаты. Однако при формировании команды мы смотрим прежде всего на опыт и достигнутые результаты в разрезе реального повышения эффективности бизнеса заказчика. Телефон: +7(495)723-26-71.