在生产中，紧急采购很少会自然而然发生。其原因可能是生产计划的变化、消耗标准的错误、供应商的延迟、设备故障或未及时提交的申请。当这些请求在通用流程之外处理时，复杂性就开始了：通过电话、在消息应用中、在零散的表格和私人信件中。
结果，批准的计划不再是一个有效的工作指引。采购人员转向最响亮的请求，仓库收到矛盾的指令，而管理者在缺货或超支后才看到后果。同时，紧急性并不总意味着危急：没有统一的秩序，很难区分紧急需求和不足的规划。
临时采购的风险
- 未经检查库存和开放交付的订单重复;
- 由于缺乏统一状态而造成的批准延迟;
- 没有变更历史的手动调整供应计划;
- 对供应商的不明确优先级和不完整背景;
- 无法快速确定偏差的原因和发起者;
- 基于不完整数据的预算、期限和风险决策。
主要任务是兼顾灵活性和控制。生产需要快速的回应，但加速不应意味着放弃限额、审批流程和正当性检查。如果规则未内置于流程中，公司要么延迟真正重要的需求，要么允许混乱的支出。
OpenBox如何将申请纳入管理轨道
在“申请管理”程序中，紧急需求被记录为带有属性、责任人与阶段的对象。用户说明需要什么，针对哪个部门或生产任务，在什么数量和截止日期。如果需要，可以记录紧急原因并附上支持材料。
单一申请取代信件往来
所有请求都通过指定的表单处理并保留变更历史。采购人员可以看到申请者、优先级、期限、审核人员、相关项目和当前状态。这减少了确认次数，并帮助确保在审核基础数据之前不启动采购。
根据规则进行路由
申请可以根据部门、金额、类别、需求类型或紧急性进行路由。为标准和临时请求设定不同的路线。对于紧急申请，可以强制要求说明理由并参与所需的管理者。这样，例外情况不会默默无视，而是作为一个可控的过程部分。
与供应计划的联系
管理者获得整体情况：计划了什么，增加了什么，哪些申请正在批准，哪些已经转入采购。变更不会在本地文件中丢失，而是成为需求历史的一部分。这使得不仅可以讨论订单，还可以讨论原因……
可以从调查当前流程和为一种类型的申请设定试点路线开始。这允许在实际工作中测试方法，确定必要的规则，并为扩展做好基础。