Jump to content

Justify Converting a “Non-Scheduled Process” to be a “Scheduled Process”


Recommended Posts

I’m currently working on project with a topic on analysis on several warehouse operations. Which scopes from receiving items up to shipping them out to the warehouse. My problem is the company is experiencing several transaction errors in their system which led to inventory inaccuracy in their records. I already did some analysis through the use of SIPOC and RCA.

One of the main errors that I found to be the cause of of such transaction errors was the unorderly queuing of how inventory is handled. Which led to missing inventory, unrecorded picking jobs, unrecorded release of parts, and etc. I have already consulted it to some of the personnel in-charge of the different warehouse processes and they do agree that implementing a scheduled process instead of a one-to-one process would indeed improve the quality of inventory handling and have an improvement in their inventory records which I also derived from the RCA analysis.

The part where I’m having a problem is how should I present these findings and justify that a conversion to a “Scheduled process” is the way to go? I’ve seen some problems quoting the improvements in process efficiency are one of the justified reasons but in my case, process efficiency is not my main concern but the inventory accuracy of the warehouse. Since this is more of a transaction type problem rather than an efficiency type, I’m having trouble justifying and presenting my findings through a cost-benefit analysis way.

Just to clarify, I’m asking if there are other ways to justify the process to be scheduled such as put-away or pulling of items other than being derived as a solution from interviews and analysis or is it being derived from an RCA enough? Also, other than efficiency ratios as well as it’s not an efficiency problem.

Link to post
Share on other sites
  • 1 month later...

Hello Andrew

 

You may present your case basis the transaction error % (effectiveness or accuracy ratio).

 

Alternatively, you may also simply look at the number of transaction errors on a daily/weekly/monthly basis. This should be done only if the total number of transactions are fixed. if the total transactions vary, then looking at standalone numbers might be mis-leading.

 

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Who's Online (See full list)

  • Forum Statistics

    • Total Topics
      2,866
    • Total Posts
      14,519
  • Member Statistics

    • Total Members
      55,062
    • Most Online
      888

    Newest Member
    Cesar
    Joined
×
×
  • Create New...