• Thanks for stopping by. Logging in to a registered account will remove all generic ads. Please reach out with any questions or concerns.

Auditor General of Canada’s report on supplying the Canadian Armed Forces

Halifax Tar

Army.ca Fixture
Reaction score
11,345
Points
1,260
https://www.canada.ca/en/department-national-defence/news/2020/07/minister-of-national-defences-statement-in-response-to-the-auditor-general-of-canadas-report-on-supplying-the-canadian-armed-forces.html?fbclid=IwAR2gYL48S9E4c840pXANDM0MrgU66g8D7shkaFCuI8TWIlFAPws4fbJHxLI

https://www.oag-bvg.gc.ca/internet/English/mr_20200708_e_43596.html

https://www.oag-bvg.gc.ca/internet/English/parl_oag_202007_03_e_43574.html

Happy reading!
 
Having now read the report, and spent the night digesting it; I have to say this had me jumping up and down saying "I told you so".  My take away is this confirms the opinions of many Sup Techs that our move to follow civilian standards of "just on time" levels of logistical support have been a failure. 

We need mass amounts of stores prepositioned in various convenient locations at all times.  And if they sit there doing nothing, thats A-Ok.  Because we (CAF) are a very large, last ditch, what-if, organization that only consumes finances while producing no physical product. 

Money needs to be reinvested back into ADM(MAT) and given to LCMMs to keep the shelves full and stream line supply processes.  And if this means first line units lose LPO budgets to buy stupid commodities so-be-it.  The Canadian Forces Supply System (CFSS) should be able to provide 95% of all requirements at all times.

We need to move away from 2 large depots of everything, too many smaller depots located insitu with the right stores that are commonly needed by its supported units/organizations. 

Just my 2 cents.
 
Each JTF in CJOC should have at least one regional supply depot operationally assigned to it for just such purposes.  Reform 1 CFSD in Toronto for JTF(C) and 5 CFSD in either Moncton or Halifax for JTF(A) with another for JTF(P) in either Vancouver or Esquimalt; I'm sure 7 CFSD in Edmonton could also support JTF(N) in a pinch for these issues.

Or more simply, allow each divisional support group to have a garrison supply battalion that could double as a regional CFSD.
 
I read the report and see the failures of LCMMs.

* Can't explain how (or if) they set stock levels.
* Critical items below minimums (which, per above, we don't know how they were set)
* 186K outstanding requests in the system

From my own experience, some LCMMs lack the knowledge of how to properly use their tools, and do not head off failures.  For example, there were certain quite high level circles in denial about the critical CADPAT shortages because they looked at overall holdings, not by NSN - but having 6000 pairs of 6428 pants on hand is not particularly useful unless we're recruiting a lot of short, thin people.

Is there a need for increased holdings in some areas?  Definitely.  Is there a need for better decision-making information?  Definitely.

However, we are not properly managing current inventories (see many OAG and internal reports over the years).  Warehousing is costly.  Storing spares for decades after a platform is retired is wasteful - that materiel should be disposed of along with the platform.  Yet a few years ago, I  was in the room while VAdm Normal (CRCN at the time) comments about the beautiful spare anchor of a St Laurent class he'd recently seen in a warehouse.  (He was joking that he hoped it would go to PSPC surplus for sale and disposition, so he could buy it for his front lawn; the only potential snag in his plan, per his words, was his wife).  That and other, similar issues are LCMM failings.
 
And if we had, oh, I don't know, a clear vision and mission, the Loggies might just be able to line up behind that more effectively too.  :whistle:
 
dapaterson said:
I read the report and see the failures of LCMMs.

* Can't explain how (or if) they set stock levels.
* Critical items below minimums (which, per above, we don't know how they were set)
* 186K outstanding requests in the system

From my own experience, some LCMMs lack the knowledge of how to properly use their tools, and do not head off failures.  For example, there were certain quite high level circles in denial about the critical CADPAT shortages because they looked at overall holdings, not by NSN - but having 6000 pairs of 6428 pants on hand is not particularly useful unless we're recruiting a lot of short, thin people.

Is there a need for increased holdings in some areas?  Definitely.  Is there a need for better decision-making information?  Definitely.

However, we are not properly managing current inventories (see many OAG and internal reports over the years).  Warehousing is costly.  Storing spares for decades after a platform is retired is wasteful - that materiel should be disposed of along with the platform.  Yet a few years ago, I  was in the room while VAdm Normal (CRCN at the time) comments about the beautiful spare anchor of a St Laurent class he'd recently seen in a warehouse.  (He was joking that he hoped it would go to PSPC surplus for sale and disposition, so he could buy it for his front lawn; the only potential snag in his plan, per his words, was his wife).  That and other, similar issues are LCMM failings.

I tend to agree that before we go down the expensive PY and infra route we should ensure we fix the things we already control and LCMMs, user knowledge and system efficiencies is where I would start.

**Disclaimer - my observations are for the most part CA centric but based on discussion with peers and SMEs much of this is applicable to the RCN and RCAF although they both have their own nuances. My observations also come from a officer/non-technical perspective, however I have run the gambit in the system from dealing at the unit to DDRMIS level. No means am I an expert, just have a good understanding of how the system works.

Technical people from the tactical to the strat level often don't understand how the system works and tend to utilize work around that require manual intervention.  Every time you have to manually intervene means that the automation of the system is defeated, we should be working towards empowering folks with knowledge of the system and making it as automated as possible.

Some examples are:

System Knowledge 
Creation of MRPs/SLOC is a nightmare as people don't understand the difference between provisioning and stocking areas so they create structures that don't match reality. For those that don't know an _S MRP is a where a unit would hold its stuff it needs to do their job (Eg: A Coy 1 PPCLI would have a SLOC under the 1 PPCLI _S MRP that holds their LAVs). A _P or provisioning MRP is a searchable area that holds stock needed on a regular basis and is usually but not consists of more consumable natures (yes even parts are consumable to a degree). To continue the example 1 PPCLI should have a QM _P MRP and a spare parts _P MRP holding stock for the unit as a whole.

What we tend to do is create overly complex structures with too many MRP _P areas that makes it confusing for the tech on the ground to know which one to target. At the tactical level having two MRPs (Material Requirements Planning ) areas both containing spare parts is something many units do. The problem is the system only searches in a linear fashion automatically  (Unit - 2nd Line spare parts - Depot) so if the part you need is held by you but not in the main MRP then the req goes to 2nd line or depot needlessly. Manual intervention in terms of redirecting the search to the right MRP in the unit slows down the process.  Solution is to move all stock under the main MRP and add Storage Locations (SLOCs) as required to differentiate different holding areas.

The above is a simple example, I have seen structure designs for expeditionary missions domestic exercises that are overly complicated and add little to no value but people don't know what the system can and can't do so they assume the complication is required.


Depot to Depot

So above I mentioned the general search string for a part generally looks like Unit - 2nd Line spare parts - Depot. That last piece is the search string only set to 7 CFSD or 25 CFSD (often based on region) and it stops there. There is no crosstalk in the system between the two depots, so if your part isn't in that particular depot then it will just sit there in limbo until someone manually intervenes. People assume that someone is working on their order but generally depot staff don't intervene (unless HPR).  The fix is to manually target the right depot when you place the order however that means you also have to do a search to see where the stock is first before placing the order again defeating the purpose of automation.  Solution is make the depots cross talk

LCMMs
Too often LCMMs set release control on parts that don't need it because that is their method of managing the stock. Ordinally release authority should be quick and not really impede the end user as it should only be set on critical supplies but that is not been my experience. The worst part is when an LCMM isn't monitoring their  requests and someone has to manually intervene by calling them or emailing to ensure that stock starts flowing.

Another issue is they have a part that is use until exhausted and then a newer part with a different NSN will takes its place. The system allows you to "merge" those two NSNs essentially so that as stock is exhausted in one NSN any future orders are automatically sent to the newer NSN but an LCMM doesn't know that functionality exists and again until someone manually intervenes orders sit in limbo.

A smaller observation is often for small ancillary nuts/bolts/gaskets etc, there is an ability to buy it on the economy if/when stocks levels nationally are low or it is time sensitive. The system again allows you to put that sort of information into the metadata for that NSN but it is a rare LCMM that will do so. Instead someone again has to manually intervene and call only to find out they can go downtown and solve their VOR problem quickly

Min/Max Levels
This is a great way to always ensure you have stock on hand in terms of setting levels that once breached automatically re-order stock to bring you up to a set level. Finding the right Min/Max levels is tricky as you want them to make sense. There is no point in holding lots of something you don't utilize all that often, nor is it useful to have a low level set for something that you do use on a regular basis.

To start not many people know how to pull parts usage numbers to be able to do a an analysis of where to set Min/Max levels, so you end up with some very weird numbers. Solution here is teach folks how to run the reports and extrapolate the data they need to set Min/Max.

The other problem is in setting Min/Max levels sections will input some great data but not turn on automatic replenishments so all that work is wasted. As a staff supply guy I would do a SIV/SAV into a unit and run a report of how many parts have a Min/Max set compared to the number that are actually turned on and often there is a huge disparity. The tech did a great deal of work (or they had DDRMIS do a batch setting) but failed to change the most crucial part that turns on the automation. Solution is getting actually teaching folks how the system works



 
Or use a system that isn’t so painfully complicated and user hostile...
 
SeaKingTacco said:
Or use a system that isn’t so painfully complicated and user hostile...

Geez thousands of companies around the world use SAP and yet their worlds aren't falling apart. I wonder if SAP is the issue or us?

Don't get me wrong it is a complicated system but we do ourselves no favours by continuing to ignore how the system works. When we adopted the system we had no idea what an ERP could do and tried to shoehorn it into what we knew which was old stovepiped legacy systems. That a decade+ later (depending on your role) we still have basic issues means we are likely more the problem than not.

DND is rolling over to the more user friendly version in the next five years but unless we change the underlying structure we are still built on a shaky foundation. 

** That said I know the RCAF aspect is a bit more nuanced given the way aircraft are managed and it is definitely not my area of expertise.  I have no doubt given the nature of flight operations there are additional hurdles faced by my RCAF brethren and their operators
 
Halifax Tar said:
We need mass amounts of stores prepositioned in various convenient locations at all times.  And if they sit there doing nothing, thats A-Ok.  Because we (CAF) are a very large, last ditch, what-if, organization that only consumes finances while producing no physical product. 

Money needs to be reinvested back into ADM(MAT) and given to LCMMs to keep the shelves full and stream line supply processes.  And if this means first line units lose LPO budgets to buy stupid commodities so-be-it.  The Canadian Forces Supply System (CFSS) should be able to provide 95% of all requirements at all times.

More and more I find myself agreeing with the idea that the CAF should be run as a business. The business of protection lets say.

If it were selling any product... shoes for example... this company would've lost its reputation, customers, and filed for bankruptcy already. A reasonable, national-level company would've seen this issue for the threat to its bottom-line survivability and invested in consultants and/or appropriate software to rectify.

If I wanna order a cool new pair of boots for the coming winter, I would've had to order them in the late summer and then I might maybe get some? With various franchises shipping my boots between them all over the country in order to make their way to me?

I know nothing of logistics, but my limited understanding says this issue could be solved by going to a COTS solution.

 
MJP said:
Geez thousands of companies around the world use SAP and yet their worlds aren't falling apart. I wonder if SAP is the issue or us?

Don't get me wrong it is a complicated system but we do ourselves no favours by continuing to ignore how the system works. When we adopted the system we had no idea what an ERP could do and tried to shoehorn it into what we knew which was old stovepiped legacy systems. That a decade+ later (depending on your role) we still have basic issues means we are likely more the problem than not.

DND is rolling over to the more user friendly version in the next five years but unless we change the underlying structure we are still built on a shaky foundation.

SAP is a really user unfriendly and counterintuitive program to use, regardless of how many companies use it. It's fundamental interface and transactions codes is a flashback to software from the 1990s, and generally the easiest way to make use of the data is to pull it out of the program and run it through a macro to generate a readable report (which usually has all kinds of incorrect information because of how the system was shoehorned onto ships with deployed servers).

We also aren't doing ourselves any favours, but anyone arguing that SAP is easy to use hasn't tried to do anything outside a specific, already templated process. There is lots of data there which isn't searchable/sortable because of how the queries are set up, and how the data is segmented in the system.

Honestly, with how much we've spent on SAP plus subsequent bespoke frontends, we could have had a tailor made ERP software developed for our specific needs, and not had to try and change how things work because of how the system is set up, and not what we really need to do. Because of how it's set up, it doesn't actually support how we have contractually set up ISSC supplies on ships, so AFAIK that kind of inventory is being managed in excel spreadsheets, because what's in SAP is not reliable.

SAP is probably excellent if you already do business in the manner the SAP workflow is set up to support, so probably pretty straightforward for a lot of commercial set ups that have JIT supply system etc. We've been adapting to the tool for a while now, so probably over the worst of it, but I know that so much of the data in it is suspect that I don't necessarily believe any report that hasn't been audited. Commercial processes work for them, but they fall apart for us pretty quick. Some stuff we could definitely do better, but a lot of the 'best practices' for business really don't make any operational sense for us when a huge part of are role is to be there for when a large variety of different scenarios hit the fan, and the 'customer' can suddenly be on the other side of the planet within a few weeks (usually with minimal connectivity available to use SAP properly, introducing all kinds of data sync errors). 
 
Navy_Pete said:
SAP is a really user unfriendly and counterintuitive program to use, regardless of how many companies use it. It's fundamental interface and transactions codes is a flashback to software from the 1990s, and generally the easiest way to make use of the data is to pull it out of the program and run it through a macro to generate a readable report (which usually has all kinds of incorrect information because of how the system was shoehorned onto ships with deployed servers).

Some familiar challenges in enterprise wide resource systems reflected here:


National Grid: A perfect storm

National Grid, a utility company serving gas and electric customers in New York, Rhode Island, and Massachusetts, was facing a difficult situation. Their rollout of a new SAP implementation was three years in the making and already overdue. If they missed their go-live date, there would be cost overruns to the tune of tens of millions of dollars, and they would have to get government approval to raise rates to pay for them. If they turned on their new SAP system prematurely, their own operations could be compromised. Oh, and their go-live was date was November 5, 2012 — less than a week after Superstorm Sandy devastated National Grid's service area and left millions without power.

In the midst of the chaos, National Grid made the fateful decision to throw the switch, and the results were even more disastrous than the pessimists feared: Some employees got paychecks that were too big, while others were underpaid; 15,000 vendor invoices couldn't be processed; financial reporting collapsed to the extent that company could no longer get the sort of short-term loans it typically relied on for cashflow. National Grid's lawsuit against Wipro, its system integrator, was eventually settled out of court for $75 million, but that didn't come close to covering the losses.

https://www.cio.com/article/2429865/enterprise-resource-planning-10-famous-erp-disasters-dustups-and-disappointments.html
 
Navy_Pete said:
SAP is a really user unfriendly and counterintuitive program to use, regardless of how many companies use it. It's fundamental interface and transactions codes is a flashback to software from the 1990s, and generally the easiest way to make use of the data is to pull it out of the program and run it through a macro to generate a readable report (which usually has all kinds of incorrect information because of how the system was shoehorned onto ships with deployed servers).

We also aren't doing ourselves any favours, but anyone arguing that SAP is easy to use hasn't tried to do anything outside a specific, already templated process. There is lots of data there which isn't searchable/sortable because of how the queries are set up, and how the data is segmented in the system.

Honestly, with how much we've spent on SAP plus subsequent bespoke frontends, we could have had a tailor made ERP software developed for our specific needs, and not had to try and change how things work because of how the system is set up, and not what we really need to do. Because of how it's set up, it doesn't actually support how we have contractually set up ISSC supplies on ships, so AFAIK that kind of inventory is being managed in excel spreadsheets, because what's in SAP is not reliable.

SAP is probably excellent if you already do business in the manner the SAP workflow is set up to support, so probably pretty straightforward for a lot of commercial set ups that have JIT supply system etc. We've been adapting to the tool for a while now, so probably over the worst of it, but I know that so much of the data in it is suspect that I don't necessarily believe any report that hasn't been audited. Commercial processes work for them, but they fall apart for us pretty quick. Some stuff we could definitely do better, but a lot of the 'best practices' for business really don't make any operational sense for us when a huge part of are role is to be there for when a large variety of different scenarios hit the fan, and the 'customer' can suddenly be on the other side of the planet within a few weeks (usually with minimal connectivity available to use SAP properly, introducing all kinds of data sync errors).

Navy Pete I had the chance to interact with SAP some 10 years ago and let me tell you there were some huge issues and it was hugely inflexible. Unfortunately the setup was not done by operational staff and we became stuck in the inertia. Many companies walked away from this process half way through. I do not think that this is particular to SAP itself but the process of turning over operational processes to not just an accountant but a program. Unfortunate to see that the same issues are being dealt with
 
suffolkowner said:
Navy Pete I had the chance to interact with SAP some 10 years ago and let me tell you there were some huge issues and it was hugely inflexible. Unfortunately the setup was not done by operational staff and we became stuck in the inertia. Many companies walked away from this process half way through. I do not think that this is particular to SAP itself but the process of turning over operational processes to not just an accountant but a program. Unfortunate to see that the same issues are being dealt with

I suspect we would have had issues with pretty much any software, but SAP seems particularly bad at forcing you to adapt the business to use the tool. Software wise, reminds me of DOS based programs in the early 90s where you would navigate via the command line and usually had list of commands printed out for reference.

Once you do something once, it's easy enough to do it again, but new queries, workflows etc can be a nightmare, and normally we would kludge our processes to fit into how SAP does it, instead of making it work us.

Once the data is in the system, you can do lots of really powerful stuff, but takes someone that really knows what they are doing, and the data has to be entered in a certain way or it can get missed (ie the wrong code in a field will mean a record won't get polled). When we're theoretically using the database to do an assessment on equipment readiness, it can be a problem, and then you get into issues of whether the consolidated results suddenly become confidential, or what data can be in the live system.
 
Navy_Pete said:
I suspect we would have had issues with pretty much any software, but SAP seems particularly bad at forcing you to adapt the business to use the tool. Software wise, reminds me of DOS based programs in the early 90s where you would navigate via the command line and usually had list of commands printed out for reference.

Once you do something once, it's easy enough to do it again, but new queries, workflows etc can be a nightmare, and normally we would kludge our processes to fit into how SAP does it, instead of making it work us.

Once the data is in the system, you can do lots of really powerful stuff, but takes someone that really knows what they are doing, and the data has to be entered in a certain way or it can get missed (ie the wrong code in a field will mean a record won't get polled). When we're theoretically using the database to do an assessment on equipment readiness, it can be a problem, and then you get into issues of whether the consolidated results suddenly become confidential, or what data can be in the live system.

To me though this really is on SAP as it's not their first rodeo. I can understand the CAF not completely understanding what they were getting into. Although I only had limited involvement I can see the appeal with having that much data at your finger tips. The problem was could the data be trusted and were the people accessing it competent to understand what the reports were saying

"and normally we would kludge our processes to fit into how SAP does it, instead of making it work us." I and many of my cohorts went the other way often getting the below sent our way from some unknown purchasing manager

3.44 a large portion of high-priority requests were flagged as high priority without justification.

 
CAF processes across the board are broken, because we do not develop expertise to challenge "we've always done it this way".

Look, for example, at messages.  Zero valid reason to use a six bit character set for communication in 2020.  Yet no one has said "Shitcan ALL CAPS" because we've all always done it that way.

Other processes are equally broken , where the rationale is lost and no longer valid, but the process is now in our DNA.
 
I hate reading the daily message file.... STOP YELLING AT ME DND!

Remember about a decade ago something came out where they were going to switch messages to normal sentences, but for some reason we stuck to the all caps format (think it had something to do with the crypto for some of our NATO allies?).  I was excited until we never changed, then disappointed all over again.

Some of our processes are definitely crazy, but SAP is still a bit nuts. The combination of the two together can be an unholy nightmare the first few times you try to do something new. We also do it to ourselves when we try and 'streamline' things. Not sure if they changed it, but for a while they only shipped high priority requests to deployed ships. Some things are difficult to do local purchases on, and there can be long lead times even if we could find it, so a few times had to jump through all kinds of hoops just to get consumables replenished. More then once routine items became critical stock because they wouldn't ship us things until it became critical; it was stupid AF. Loved trying to explain it to our NATO counterparts; had to repeat parts of it a few times because they thought they missed something due to a language barrier (they didn't, it really was that stupid).

That is one thing I'm looking forward to with the ISSCs; our contracts encourage them to make sure the ship has all parts needed for maintenance, so they will probably arrange for standard replenishment of stock throughout a deployment. It's pretty easy to forecast, as there is lots of stuff that gets used regularly and needs replenished as we can only carry a few months worth (or less) on board.
 
MJP said:
Geez thousands of companies around the world use SAP and yet their worlds aren't falling apart. I wonder if SAP is the issue or us?

Don't get me wrong it is a complicated system but we do ourselves no favours by continuing to ignore how the system works. When we adopted the system we had no idea what an ERP could do and tried to shoehorn it into what we knew which was old stovepiped legacy systems. That a decade+ later (depending on your role) we still have basic issues means we are likely more the problem than not.

DND is rolling over to the more user friendly version in the next five years but unless we change the underlying structure we are still built on a shaky foundation. 

** That said I know the RCAF aspect is a bit more nuanced given the way aircraft are managed and it is definitely not my area of expertise.  I have no doubt given the nature of flight operations there are additional hurdles faced by my RCAF brethren and their operators

I'm totally in agreement that numerous retail companies do inventory management through SAP and many work brilliantly. I can go to various retail site that use various software solutions--Canadian Tire, Lowes, Home Depot--and find out if the item I'm looking for is in stock, how many there are or where the nearest location is that has my item. The clerks in the store can find out exactly where in the store the items are (on a shelf or in back-room stock)

These programs work on a front end with a very friendly user interfaces, a central database and a system of connections and protocols that recognize usage rates, low stock and re-order interconnects with a myriad of suppliers. SAP isn't so much the problem; its how its utilized that creates issues. One of the biggest and most expensive SAP failures was the billion dollar plus boondoggle of Target Canada which basically fell apart on how the software solution was implemented. Failures went from the highest to the lowest levels. See here. It wasn't so much the software itself but it's implementation (especially interesting because the US system was quite robust and operational for many years-so there was plenty of experience available to draw on)

Honestly, If we want to know how to run a high volume inventory warehousing and order/reordering system go see Lowes and some of the other big folks and then don't do what Target did.

:cheers:
 
I helped my friend sell landrover parts, a potentiel of 50,000 different pieces. His tracking system which used 3.5`floppies for back up, could track how much we had of each part, how many we sold by any timeframe, who we sold them to, how much they cost and how much they sold for, how each customer paid. It also did invoicing sales and ordering new parts. This was in the early 90's. When I was working in our unit QM we found out that by putting a W into one box of the 2302 form, overrode the authorized level for ordering equipment. This allowed us to actually stock stuff we needed. What I did note that the supply chain was over enthusiastic about surplussing equipment when there was no replacement in sight, whether it was a truck or a desk. We had to fight tooth and nail to hold onto our 3 ton stake truck, which allowed us to do supply runs to Chilliwack and back without putting excess miles on our tired deuces. The system had no replacement for it,  and no one seem to care about the situation as long as the process was being followed, not the result. 
 
Navy_Pete said:
SAP is a really user unfriendly and counterintuitive program to use, regardless of how many companies use it. It's fundamental interface and transactions codes is a flashback to software from the 1990s, and generally the easiest way to make use of the data is to pull it out of the program and run it through a macro to generate a readable report (which usually has all kinds of incorrect information because of how the system was shoehorned onto ships with deployed servers).

We also aren't doing ourselves any favours, but anyone arguing that SAP is easy to use hasn't tried to do anything outside a specific, already templated process. There is lots of data there which isn't searchable/sortable because of how the queries are set up, and how the data is segmented in the system.

This is very true, most companies that adopt SAP also customize their UI and their reports so the data doesn't have to be re-manipulated and users have an easier time with the program.  Guess who decided to not do that? Well not totally true we did make a number of very specific reports for some things not contained in organic SAP but we also made a bunch that replicated SAP processes already in play

That said we have had great success over the past few years in changing reports to be able to collate data. I was a small bit player in tying our work order and supply processes into a better report that both sides could utilize. It took some work  a few briefing notes and a bit of pressure  but we got it done.

I am certainly aware there areissues with SAP believe me it isn't perfect but for the most part we seem to be the problem in a number of regards.  Reminds me o

Navy_Pete said:
Because of how it's set up, it doesn't actually support how we have contractually set up ISSC supplies on ships, so AFAIK that kind of inventory is being managed in excel spreadsheets, because what's in SAP is not reliable.

It would be interesting to see what the underlying issue is here. This sounds very similar to the teething issues the TAPV project had in DRMIS due to having to utilize another plant to meet the criteria of the contract.  Caused a number of unforeseen issues at a number of levels.

FJAG said:
I'm totally in agreement that numerous retail companies do inventory management through SAP and many work brilliantly. I can go to various retail site that use various software solutions--Canadian Tire, Lowes, Home Depot--and find out if the item I'm looking for is in stock, how many there are or where the nearest location is that has my item. The clerks in the store can find out exactly where in the store the items are (on a shelf or in back-room stock)

These programs work on a front end with a very friendly user interfaces, a central database and a system of connections and protocols that recognize usage rates, low stock and re-order interconnects with a myriad of suppliers. SAP isn't so much the problem; its how its utilized that creates issues. One of the biggest and most expensive SAP failures was the billion dollar plus boondoggle of Target Canada which basically fell apart on how the software solution was implemented. Failures went from the highest to the lowest levels. See here. It wasn't so much the software itself but it's implementation (especially interesting because the US system was quite robust and operational for many years-so there was plenty of experience available to draw on)

Honestly, If we want to know how to run a high volume inventory warehousing and order/reordering system go see Lowes and some of the other big folks and then don't do what Target did.

:cheers:

I can't speak for how we integrated SAP/DRMIS at a high level but can say from user perspective we really cheaped out on implementation and adopted a very Phoenix like approach to training considering that the person that did the staff officer training was a Class B MS Naval Hull Tech IIRC and the course itself was almost entirely useless. My peers and I were lucky at the time that we had a boss that worked on the early stages of project and his 2IC who was a genius in SAP, so we avoided many of the issues that other areas had and rolled over and knew the system fairly well. We had to do it ourselves cause for the most part from the L4-L1 level there are only isolated pockets of folks (CA) that know what they are talking about and in the early days the CA didn't even have a dedicated team at the L1 level.  That came much later and they have been a force multiplier when it comes to fixing issues but we still have a very distinct lack of knowledge at the lower end of the spectrum.


https://en.wikipedia.org/wiki/Phoenix_pay_system
In March 2014, according to an IBM spokeswoman, the Crown took over responsibility for "training design and execution" from IBM," in a cost-saving measure. The government adopted a 'train the trainer' approach rather than follow IBM's recommended system.[12]


 
The go-live of MASIS was delayed, but the harvesting of PYs from the Level 1s as savings that ADM Mat had promised were not.

So just as the initiative should have been ramping up personnel to manage the transition, we got rid of them instead.
 
Back
Top