Как учесть специфику производства и при этом не превратить 1С:ERP в сложную самописную систему? Разбираем принципы проектирования, роль АРМов, критерии необходимости доработок и подход к поэтапному развитию производственного контура.
На производственных проектах существует понятное желание учесть все особенности предприятия. Производство действительно редко работает строго по универсальной схеме: существуют собственные документы, привычные формы заданий, особенности планирования, сложившиеся правила взаимодействия между подразделениями.
Но именно здесь возникает один из главных рисков проекта - попытка перенести в новую систему каждую особенность существующего процесса.
Результатом может стать решение, которое формально точно соответствует требованиям, но дорого развивается, сложно сопровождается и требует большого объема обучения и работы конечных пользователей.
Задача проектирования заключается не в том, чтобы автоматизировать максимальное количество особенностей. Она заключается в том, чтобы найти минимально достаточную модель, которая решает реальные задачи предприятия и остается поддерживаемой после проекта.
Когда существующий процесс отличается от стандартной логики системы, естественная реакция - выполнить доработку типовой 1С:ERP.
Но само наличие отличия еще не является основанием для разработки.
Сначала необходимо понять, почему процесс устроен именно так. Возможно, существующий порядок сформировался из-за ограничений предыдущей системы, исторических причин или использования Excel. После перехода на ERP часть этих ограничений исчезает.
Поэтому в рамках проекта правильнее решать не задачу «как повторить этот процесс в новой системе», а «какой бизнес-результат этот процесс обеспечивает».
После этого можно искать наиболее простой способ получить тот же результат средствами целевой системы.
При этом противоположная крайность не лучше.
Неправильно отказываться от необходимого решения только потому, что его нет в стандартной поставке в требуемом виде.
Если особенность производства действительно критична, дает бизнесу значимый результат и не может быть реализована иначе, доработка оправдана.
Поэтому выбор между типовым механизмом и разработкой должен быть архитектурным решением, а не идеологической позицией.
Полезно проверять каждую потенциальную доработку тремя вопросами:
Если убедительного ответа на первый вопрос нет, возможно, разработка не нужна.
Производственный пользователь не обязан понимать внутреннюю архитектуру ERP.
Мастеру цеха, диспетчеру или сотруднику склада обычно нужен ограниченный набор конкретных сценариев: зарегистрировать событие, увидеть необходимые данные, принять решение и зарегистрировать результат.
Если для отражения одной производственной операции пользователю необходимо вводить несколько документов, открывать разные разделы системы, искать связанные данные, процесс становится сложным независимо от того, насколько методологически правильна внутренняя модель.
Поэтому в производственных проектах особенно полезны автоматизированные рабочие места - АРМы.
Хороший АРМ объединяет в одном интерфейсе действия конкретной роли и помогает работать с основной системой через понятный бизнес-сценарий.
При этом важно не превратить АРМ в отдельную информационную систему внутри ERP.
Чем больше собственной логики, собственных состояний и самостоятельных данных появляется в рабочем месте, тем сложнее его сопровождать.
Оптимальная модель - когда АРМ упрощает доступ к данным и действиям ERP, но не создает параллельный контур учета.
На производственных проектах 1С:ERP финансовую часть иногда откладывают на конец, сосредоточившись сначала на задачах производства.
Это серьезный риск.
Любое решение по регистрации выпуска, передаче материалов, выполнению этапов и изменению незавершенного производства в конечном итоге влияет на себестоимость.
Поэтому проектирование должно проходить сквозным образом: от действия пользователя в производстве до конечного отражения результата в требуемой финансовой аналитике.
Если удобное производственное решение не позволяет сформировать необходимую себестоимость или закрыть период в бухгалтерском учете, его придется переделывать. Базовый расчет себестоимости нужно проводить еще на стадии моделирования будущей системы.
Именно поэтому хороший модельный пример не должен заканчиваться фразой «продукция выпущена». Необходимо проверить, что стало с материалами, затратами, незавершенным производством и себестоимостью.
Бывает, что предприятие должно запустить новую ERP в определенный срок, но производство еще не готово к полномасштабному внедрению функционала 1С:ERP.
Не подготовлены нормативы, сотрудники не готовы работать с большим количеством новых документов, отсутствует необходимая дисциплина регистрации.
В такой ситуации попытка любой ценой запустить максимально детальный производственный контур может увеличить риск всего проекта.
Возможна другая стратегия - использовать на первом этапе более простую модель и параллельно готовить предприятие к следующему уровню.
Например, на некритичных производственных переделах можно временно использовать производство без заказов, не вводя детальный учет через заказы на производство и этапы. Параллельно следует формировать и уточнять ресурсные спецификации, чтобы после подготовки НСИ и отработки процессов перейти к полноценной производственной модели.
Главное условие - временное решение должно иметь понятный путь развития.
Если упрощение приводит к тому, что производственная НСИ вообще перестает развиваться, временная схема быстро превращается в постоянную проблему.
Чем подробнее система описывает производство, тем больше информации нужно поддерживать.
Каждый дополнительный этап, статус, документ или реквизит требует действий пользователей. А каждое действие должно иметь бизнес-смысл.
Поэтому полезно смотреть на проектирование через стоимость владения будущим процессом.
Дополнительные пять минут работы одного пользователя могут казаться незначительными. Но если действие выполняется сотнями сотрудников каждый день, оно превращается в существенные операционные затраты.
Поэтому при внедрении нужно оценивать не только возможность реализации требования, но и цену его существования в системе.
До масштабной разработки стоит пройти основные сценарии на модельном примере.
Причем проверять необходимо не только идеальный процесс.
Нужно смотреть, что произойдет при нехватке материала, изменении задания, замене, возврате, браке, поломке оборудования или другом характерном отклонении.
Именно на этих ситуациях чаще всего становится понятно, соответствует ли выбранная архитектура реальной жизни.
Чем раньше проблема обнаружена в ходе моделирования, тем дешевле ее исправить.
Хорошая архитектура производственной системы - не та, в которой реализовано больше функций.
Она должна обеспечивать необходимый бизнесу результат с минимально достаточной сложностью и оставлять понятный путь дальнейшего развития.
Для этого необходимо сначала искать решение в стандартном функционале, проектировать АРМы (автоматизированное рабочее место) как удобный интерфейс, а не параллельную систему, проверять финансовый результат одновременно с производственным процессом и осознанно выбирать глубину автоматизации.
Избежать избыточных доработок и сохранить систему поддерживаемой — реально. Мы поможем вам найти минимально достаточную модель, настроим удобные АРМы для производственных пользователей и обеспечим сквозную связь с финансовым учётом. Не усложняйте там, где можно проще — доверьте проектирование профессионалам.
Обращайтесь по телефону +7 (495) 989-22-16 или email: sales@rg-spc.ru.
Веб-студия SeoLand: Создание и продвижение сайтов
Наш сайт использует файлы cookie для обеспечения удобства пользователей сайта, его улучшения, сбора статистики и предоставления персонализированных рекомендаций.
Для получения дополнительной информации о целях, сроках и порядке использования файлов cookie вы можете ознакомиться с нашей Политикой обработки файлов cookie
