Tag Archives: APS

Notes on Scheduling and Costing in CSI/Syteline

We had some initial struggles getting running on our CSI implementation so we started with one of our smaller operations. We had very little guidance with several nuances with the package (it’s a long story that’s not fit for print) so I’m going to touch upon them here, but, the overarching rule is thus: routers need to be correct so that both costing and scheduling is correct. If the routers are bad, both the costing and scheduling will not work as designed in CSI.

To begin, all manufactured parts in CSI need a router to be setup up in Current Operations and Current Materials. In other systems these are called the “job templates”, though in CSI there is only one ‘true template’. I will point out that this mostly applies to the APS flow in an actual costed environment. I do suppose that it is possible to use a standard costed system and ignore the scheduler and in that case perhaps the ‘Currents’ are not needed. However, I think that is still bad form since the system will then not have a baseline to compare actual production values to. It is possible for the numbers to be compared to the standard but the standard is just an educated guess made by an, no doubt talented, accountant while the “planned cost” that is derived from the router is a ‘guess’ made by production.

Properly constructed routers have another benefit too: if the job cost variance report shows a very odd “planned cost” then that probably means that there is an issue with the router that may show up in scheduling the job. In this way production and accounting get actionable data out of the same single data set.

As well, this planned cost is critical in an actual costed environment. In CSI if a partial job quantity is moved in to inventory, how does CSI know how to cost it since not all the costs have been incurred on the job? The answer: it uses that planned cost. Thus it is critically important that the planned be as close to the actual as possible (think of it like a standard cost that isn’t actually standard). When the job is closed out the difference between the planned and the actual is sent to the inventory adjustment account in CSI. The correct sequence for inventory moves when using actual costing in CSI then is:

  • If the job is being moved into inventory complete, then close the job and move the inventory at the same time.
  • If there have been any partial moves from the job into inventory, then move all the parts as partial and close the job out separately (within the Job Orders form).

I found the operation and tuning of APS itself pretty straightforward with two notable exceptions:

  1. Forecasting does not work. Well, I take that back, there are a narrow set of circumstances where the Forecasting function might work but I’ve been unable to find anyone that it would work for. The workaround for this is to put a bogus sales order into the system that serves as the forecast (and manually deducting the forecast as its consumed).
  2. APS handles Setup times very poorly in that it doesn’t roll the Setup resource group off of the job after the setup is complete. Part of this probably has to do with the fact that CSI has no way to know if a setup is complete. The workaround for this is to put the setup on the router as a separate operation. This can lead to some wonky views in the scheduler since there is no guarantee that the machine being setup is the same one that will be doing the run, BUT, the throughput will be correct.

We also ran into two other issues that were no fault of the package. In one instance, some of our routers were very inaccurate and it was very difficult to get them fixed so the planning people resorted to marking the parts as MRP which forces APS to use whatever lead time it is told. The other issue had to do with a change in methodology since it’s important that the operations are closed out as they are completed, otherwise APS leaves the whole time scheduled. This was something we had to work on with the employees so that they knew when (and when not) to close out an operation.