При выборе программного обеспечения для производства обуви компании часто сталкиваются с типичной дилеммой. С одной стороны, список функций ослепительно длинный, от определения объема производства до калькуляции затрат, от штрих - кода до мобильного утверждения, как будто каждый поставщик утверждает, что он всемогущ; С другой стороны, слишком много случаев неудач вокруг, система простаивает после выхода в сеть, данные не соответствуют, сотрудники не хотят использовать, миллионы инвестиций в дрейф. Это беспокойство не лишено причины. Бизнес - процессы в обувной промышленности чрезвычайно специфичны, общий ERP не подходит, а профессиональное обувное программное обеспечение имеет разное качество. Благодаря успехам и неудачам ERP в обувной промышленности Shuntong в десятках обувных компаний можно четко определить три основных закона, которые проходят через весь процесс отбора. Эти три правила не являются горизонтальным перечислением таблиц функционального сравнения, а определяют, сможет ли программное обеспечение укорениться на обувной фабрике.
Первый ключевой момент - это отраслевая адаптация, а не многофункциональность, а функциональная точность. Многие обувные компании легко впечатлены большими и полными функциональными демонстрациями при выборе, но игнорируют, действительно ли самые повседневные и частые операционные сценарии программного обеспечения понимают. Ранние ERP обувной промышленности Shuntong столкнулись с серьезным сопротивлением на фабрике женской обуви в Хуэйдуне по очень конкретной причине: система не поддерживает управление номером цилиндра обуви. Каждая партия кожаной ткани, закупленной на этом заводе, имеет разницу в номере цилиндра, и решающий цех должен строго пропорционально распределить материал по номеру цилиндра, иначе готовая обувь будет иметь различимую цветовую разницу невооруженным глазом. Стандартный продукт Shuntong просто и грубо унифицирует номер партии материала, не может отличить один и тот же материал от разных номеров цилиндров складского положения и приоритета получения. Когда цех получает материал, система показывает наличие запасов, физический является неправильным номером цилиндра, рабочие должны сначала получить материал из хранилища, а затем вручную отметить, через полмесяца системный запас полностью отделен от физического.
Эта неудача заставила Шуньтуна глубоко осознать, что отраслевая адаптация программного обеспечения для производства обуви - это не абстрактная концепция, а точный ответ на ряд конкретных сценариев. Последующая версия Shuntong реконструировала модель партии материала, встраивая номер цилиндра, цвет, ширину, дату складирования в каждое отдельное измерение складирования. При выборе предприятия следует задавать вопрос не о том, « есть ли в системе модуль управления запасами», а о том, « может ли система поддерживать управление библиотекой с разными номерами цилиндров одного и того же материала, передовым перехватом первого выхода и предупреждением о риске цветовой аберрации». Та же проблема должна возникать на каждом из основных бизнес - узлов: может ли производственный модуль распознавать технологический порядок, в котором шов обуви должен быть прикреплен до подошвы? Может ли модуль калькуляции затрат обобщать потери и часы иглы по заказу? Может ли модуль отслеживания качества проследить возврат готовой продукции от конкретного поставщика тканей и рабочей группы в течение пятнадцати минут. Эти сценизированные вопросы имеют гораздо большую ценность для скрининга, чем « поддерживается ли мобильное одобрение».
Второй ключевой момент - это возможности управления данными, а не программное обеспечение в сети, а данные в сети. Провал обувной промышленности Shuntong ERP на заводе по производству спортивной обуви в Цзиньцзяне, провинция Фуцзянь, является негативным случаем уровня учебников. Предприятие работает в течение восемнадцати лет, правила кодирования материалов претерпели эволюцию после трех менеджеров склада, одна и та же черная сетка в системе имеет семь разных названий, отдел закупок использует номер поставщика, отдел производства использует внутреннее сокращение, финансовый отдел в соответствии с общей классификацией. Консультанты по внедрению Shuntong неоднократно подчеркивали важность очистки данных на этапе исследования, владельцы бизнеса устно поддерживали, на самом деле только два клерка работали сверхурочно в течение недели, чтобы собрать 3000 файлов материалов. В первый месяц на линии заказ на закупку не может автоматически связываться с рабочей накладной из - за кодирования материалов, система при отправке склада показывает достаточный запас, но физический не соответствует, производство приостановлено в течение трех дней. Финансовый учет затрат показывает разницу в расходе одной и той же обуви в разных рабочих листах на 20%, поэтому невозможно определить, какие данные являются точными.
Этот случай раскрывает жестокую реальность: программное обеспечение для производства обуви не будет автоматически очищать данные, оно просто разоблачает управленческие долги компании за последние годы. При выборе программного обеспечения компании должны одновременно оценивать свою базу данных и методологию управления данными поставщиков. Позже Shuntong обобщил набор стандартных процессов очистки данных, от классификации материалов, правил кодирования, спецификаций имен до инвентаризации исторических запасов, каждый узел имеет четкие стандарты доставки и инструменты приемки. Корпоративный выбор должен потребовать от поставщиков предоставить фактические примеры управления данными, а не оставаться на уровне риторики « у нас есть инструменты для импорта данных». Что еще более важно, владельцы бизнеса должны четко понимать, что очистка данных - это не работа ИТ - отдела, а общая ответственность руководителей четырех бизнес - отделов: закупок, производства, складирования и финансов. Кто предоставляет правила классификации материалов, кто утверждает заявки на кодирование и кто несет ответственность за исторические различия в запасах, эти права собственности должны быть четко определены до того, как программное обеспечение будет запущено в Интернете.
Третий ключевой момент - это способность внедрять услуги и организационные изменения, а не обучать операции, а восстанавливать привычки. Shuntong обувная промышленность ERP в процессе реализации бренда мужской обуви в Вэньчжоу, все предыдущие показатели показывают оптимизм: тщательное исследование спроса, прочная очистка данных, участие ключевых пользователей высокое. Однако через три месяца после того, как система была запущена, качество данных начало падать. Комплекс команды реализации обнаружил, что корень проблемы лежит в мастерской первой линии. Руководитель формовочной линии считает, что после завершения каждого процесса подметание кода профсоюза замедляет производственный ритм, соглашаясь с тем, что рабочие сначала работают, а затем заполняют счета и даже накапливают до часа до работы, чтобы централизованно вводить. Данные о рабочем времени в системе сильно искажаются, а калькуляция расходов теряет свою справочную ценность. Казначейство требует, чтобы склад строго соблюдал передовой первый выход, администратор склада испытывал проблемы и продолжал следовать старой привычке « добывать материалы поблизости». Консультанты Shuntong неоднократно обучают рабочие шаги, все экзамены по обучению персонала квалифицированы, но после возвращения на рабочее место все еще идут своим путем.
Эта неудача заставила Huncomm пересмотреть границы реализации услуг. Обучение работе может только решить проблемы, которые не будут, и не решит желаемых проблем. Последующая деятельность Shuntong добавила « анализ корреляции интересов» в методологию реализации, чтобы разобраться в связи между работой системы и ее личными интересами для каждой ключевой должности. Руководитель формирования сопротивлялся сканированию кода, потому что предыдущая производительность была источником его управленческой власти, и система визуализировала эффективность, чтобы он чувствовал себя под наблюдением. Решение заключается не в том, чтобы усилить обучение, а в том, чтобы включить руководителя группы в группу по повышению эффективности, которая использует системные данные, чтобы помочь ему выявить узкие места в производственной линии и предоставить ему право корректировать распределение процессов. Управляющий складом не хотел выходить первым, потому что поиск нижних полок увеличивал физические нагрузки. Решение заключается не в штрафах, а в добавлении коэффициента вознаграждения за « снижение вялого материала» к служебной аттестации и одновременной закупке партии высокорегулируемых сортировочных лестниц.
При выборе программного обеспечения для производства обуви предприятия должны оценивать методологию внедрения поставщика так же тщательно, как и функции программного обеспечения. Как они распознают скрытое сопротивление ключевых пользователей? Как урегулировать межсекторальные конфликты интересов? Как увязать показатели оценки системы с вознаграждением сотрудников? Стандартных ответов на эти вопросы нет, но зрелая команда по внедрению должна иметь зрелую структуру реагирования. Успех Shuntong на другом обувном предприятии в Вэньчжоу объясняется именно тем, что до подписания контракта с предприятием была разработана шестимесячная « дорожная карта по формированию привычки», в которой системные операции были включены в описание должностных обязанностей, а точность данных была тесно связана с ежеквартальным бонусом для руководителей отделов.
Три ключевых момента ERP в обувной промышленности на самом деле являются тремя прогрессивными вопросами. Отраслевая адаптивность отвечает: « Это программное обеспечение не для обувной промышленности», возможности управления данными отвечают: « Готовы ли предприятия к цифровому обзору», а способность внедрять услуги и организационные изменения отвечает: « Может ли программное обеспечение и бизнес развиваться вместе? » На эти три вопроса нет ответа раз и навсегда, но каждый последующий вопрос сводит решение о выборе с неглубокого сравнения цены и функции к глубокому соответствию стратегии и возможностей.
Те, которые были отложены в углу склада, системные запасы показали нормальное, но бесстрашное программное обеспечение, и другая обувная фабрика, которая также использовала плавный и складской оборот на 30% быстрее, по существу использовали тот же код. Разница не в функциональности, а в том, покупает ли компания ее как набор инструментов или инвестирует в нее как отправную точку для управленческих изменений. Эта отправная точка выбрана правильно, и последующий путь имеет направление.