Наибольший страх руководителя при внедрении новой системы — это риск превратить гибкий бизнес в бюрократический хаос, где настройки программы тормозят реальную работу. Как правильно перенести привычные коммуникации и срочные задания менеджеров в BAS, не повлекши «ступор» подразделений? Разбираемся, почему старые привычки не стоит слепо копировать в новую инфраструктуру и настроить тяжелые отчеты и доработки без риска для системы.
Как правильно переносить документооборот и коммуникации, уже исторически сложившиеся на нашем предприятии без фиксации в программе, в новую программу? Например, каковы возможности работы с заказами менеджеров на срочную уборку/разборку, закупку товара и прочее? Не приведет ли перенос всех бизнес-процессов и коммуникаций к ступору в работе из-за того, что администрирование в программе будет сложнее, чем было до этого?
Если ответить кратко, то правильно – не переносить вообще, а каждый процесс переосмысливать уже в новой инфраструктуре. Ибо попытка простого переноса процесса приведет, по вашему слову, к ступору. То есть не обязательно, но достаточно вероятно.Поэтому принимая решение рассматривать необходимость организационных изменений, в том числе.
Конкретные возможности будут рассматриваться на курсах, и желательно еще и закрепить полученные навыки так, как описано в статье. систему.
Что категорически нельзя делать в программе? Как тестировать новые настройки без приостановки работы бизнеса? Как делать сложные отчеты (ABC-XYZ), чтобы это не тормозило работу несвязанных подразделений?
Можно делать все, если делать с умом 😊 Если серьезно, то это очень специфические вопросы на которые трудно дать какой-то универсальный ответ. Типичный программный код достаточно хорошо оптимизирован, работает на больших объемах данных, и есть много средств тяжелые процессы запускать ночью, по расписанию. При изменении типового программного кода нужно соблюдать определенные правила, и все также будет нормально работать.
