4 ms·

Shadow systems are prevalent in large MNC's where systems are decided centrally without being able to take into consideration local needs. Local parts of the M

by Maxion 6y ago

Shadow systems are prevalent in large MNC's where systems are decided centrally without being able to take into consideration local needs. Local parts of the MNC's end up using the centrally required system, as well as their own local shadow system.

ineedasername 6y ago
I've been involved in the selection & implementation of multiple systems like this, and there was a reasonable effort to include stakeholders from functional areas. After the RFP responses and selection of potential vendors, they each come in we had basically a week-long conference with sessions for functional areas, technical areas, implementation, etc before selecting the vendor. Even then, the problem wasn't lack of consideration for local needs: The problem was that pretty much every question asked of the vendor's demo team was "Sure we can do that, it's just a configuration!" or "That's a customization that a few of our customers have implemented, we can piggyback on their work to do the same for you!" Then implementation comes along and what were claimed to be configurations are more like "You just rewrite this COBOL module, but updates will break it so you'll need to rewrite it for every update." And those shared customizations just never materialized. In one case the actual "built in" functionality shown via screenshot slides literally didn't exist in the actual product. ::ahem Oracle:: and resulted in a lawsuit for it, among other things like like deadlines they didn't meet and & refused to complete without being paid an additional exorbitant fee, even though it was a fixed-price contract. Also yes, there are IT departments that take a request that's basically "Please create this database trigger" and run it through multiple layers of review & approval & business case justification, ROI, etc over the course of months for something that would take about 10 minutes to implement in a test environment, another hour to sufficiently test, and another hour to pass to UAT so they can confirm it's working as desired, and push to production. So you're absolutely right: I missed a causal category for shadow systems. Honestly I don't even think shadow systems are inherently bad in some cases: I just think there should be formal documentation lodged with IT so there's institutional awareness of it, and the departure of a single employee who created it doesn't cripple a department. This crippling of a department is something I've actually seen.

by Maxion 6y ago

ineedasername 6y ago

I've been involved in the selection & implementation of multiple systems like this, and there was a reasonable effort to include stakeholders from functional areas. After the RFP responses and selection of potential vendors, they each come in we had basically a week-long conference with sessions for functional areas, technical areas, implementation, etc before selecting the vendor. Even then, the problem wasn't lack of consideration for local needs: The problem was that pretty much every question asked of the vendor's demo team was "Sure we can do that, it's just a configuration!" or "That's a customization that a few of our customers have implemented, we can piggyback on their work to do the same for you!" Then implementation comes along and what were claimed to be configurations are more like "You just rewrite this COBOL module, but updates will break it so you'll need to rewrite it for every update." And those shared customizations just never materialized. In one case the actual "built in" functionality shown via screenshot slides literally didn't exist in the actual product. ::ahem Oracle:: and resulted in a lawsuit for it, among other things like like deadlines they didn't meet and & refused to complete without being paid an additional exorbitant fee, even though it was a fixed-price contract. Also yes, there are IT departments that take a request that's basically "Please create this database trigger" and run it through multiple layers of review & approval & business case justification, ROI, etc over the course of months for something that would take about 10 minutes to implement in a test environment, another hour to sufficiently test, and another hour to pass to UAT so they can confirm it's working as desired, and push to production. So you're absolutely right: I missed a causal category for shadow systems. Honestly I don't even think shadow systems are inherently bad in some cases: I just think there should be formal documentation lodged with IT so there's institutional awareness of it, and the departure of a single employee who created it doesn't cripple a department. This crippling of a department is something I've actually seen.