Live data from Hacker News

When Employees Use Software That IT Hasn’t Approved

hbr.org

301–310 of 326 posts

Re: When Employees Use Software That IT Hasn’t Approved

#301

Isn't IT something from the past? I would expect people knowing how to use a computer and what they need to do their job.

> Isn't IT something from the past?

No.

> I would expect people knowing how to use a computer and what they need to do their job.

Yes, but their job generally isn't maintaining the computer or it's supporting infrastructure (networks, shared servers, etc.) or, outside of dedicated programmers, programming the computer even as an incidental task. IT exists to do (or coordinate contracting out for) those things, and the last point—restricting programming to dedicated programmers, has pretty much monotonically increased since the 1980s, when incidental programming was both more common than now and frequently projected to become increasingly common (lots of people said all good jobs would require some.)

Re: When Employees Use Software That IT Hasn’t Approved

#302

Isn't IT something from the past? I would expect people knowing how to use a computer and what they need to do their job.

My thoughts exactly. It's been a while since I last saw a company with an actual IT department and even longer where they had an actual clue. The reality is that IT in most SMEs simply sucks and no longer requires a college education. Working in IT for an SME is not a career plan. You're at constant risk of being outsourced and essentially all you do is done better by a gazillion companies as a service that probably…

> My thoughts exactly. It's been a while since I last saw a company with an actual IT department and even longer where they had an actual clue

Let me guess: most of your recent experience is with relatively new and/or small companies, probably in the tech industry.

Re: When Employees Use Software That IT Hasn’t Approved

#303

Earlier quoted context omitted.

> SOC2/HITRUST/SOX all mandate the removal of admin rights from computers, mandate an approval process w/ manager approval I’ve heard this before, but never with any detail. Can you explain further, or point to a resource? For example, clearly SOX doesn’t say that nobody can have admin rights - because IT does. And I highly doubt that the law says that only departments with IT in the title can have admin access. So w…

tyingq summed it up tersely pretty well in the sibling comment. Specifically for SOX, it is all about financial information, but that information is stored and manipulated using computers, so IT related controls end up being part of it. It's easy to get away with sourcing your controls from an industry standard list of controls appropriate for SOX, but these are often significantly behind the times and don't acknowle…

Great comment, and does a good job of going deeper on my, as you say...terse summary.

The truth is that most of what people do in the name of SOX is cargo culting other people's ideas of appropriate controls.

In this case, you could give admin access to whoever you want. You just need reasonable documented controls around it.

Re: When Employees Use Software That IT Hasn’t Approved

#304
post #103
post #68

Earlier quoted context omitted.

The funny thing is that they block Dropbox but then there are plenty of shady upload sites that aren’t blocked. We don’t use them because we think they aren’t secure but our IT guys would have no problem with that.

That highlights a problem woven through the industry which is that the IT department isn’t always the sharpest team in the building, even on security matters.

[deleted]

Re: When Employees Use Software That IT Hasn’t Approved

#305

Earlier quoted context omitted.

We've got a Salesforce implementation going at the nonprofit where I work. While there was some debate about which big CRM we'd buy, the need to consolidate was blindingly obvious. Why? Because our organization has been quite forward thinking about allowing managers and executives to source the technology they think they to succeed. As this article advocates for, IT was largely consultative rather than dictatorial, a…

Your problem statement does make it sound like you need a CRM, but I do wonder why is has to be a big CRM with a big consultancy, and why IT aren't delivering it? Who's going to run the thing afterwards? Will the bigdogs deliver something that you can maintain, or is that generally against their own interests? Finally, who's gonna secure all this customer data? Are they taking that on as part of their remit? They rar…

The CRM needed to be sophisticated enough to accommodate high standards for data security and access control, several marketing integrations, and the complex data model that resulted from a permissive culture.

I'm NOT an expert but my understanding is that, in terms of complexity and cost, there's a whole tier above Salesforce where you're provisioning servers and installing Oracle or SAP. We didn't need and could not afford that.

And if you're thinking of smaller CRMs like Hubspot, Zoho, Sugar, Apptivo, or building one from scratch, well, we already had many of those. :-) Those are what Salesforce is replacing.

Our IT department is superb on metrics like security and availability. But they don't know Salesforce, and are not the right people to evolve the broader culture associated with data. The org hired a leader with experience doing this sort of thing, and he is building out an internal permanent Salesforce team which will own the thing after implementation is done.

Re: When Employees Use Software That IT Hasn’t Approved

#306
post #186

Earlier quoted context omitted.

We've got a Salesforce implementation going at the nonprofit where I work. While there was some debate about which big CRM we'd buy, the need to consolidate was blindingly obvious. Why? Because our organization has been quite forward thinking about allowing managers and executives to source the technology they think they to succeed. As this article advocates for, IT was largely consultative rather than dictatorial, a…

One of the side-effects I'm seeing of GDPR is a stronger incentive to consolidate systems under central management. Companies that allowed different departments the leeway to control their own systems now find themselves literally not knowing how many different places a customer's data might live.

That was absolutely a factor in this decision. And it's not just GDPR, many states and even the federal government are likely to impose more regulation on how personal data is collected and stored.

Re: When Employees Use Software That IT Hasn’t Approved

#307
post #303

Earlier quoted context omitted.

tyingq summed it up tersely pretty well in the sibling comment. Specifically for SOX, it is all about financial information, but that information is stored and manipulated using computers, so IT related controls end up being part of it. It's easy to get away with sourcing your controls from an industry standard list of controls appropriate for SOX, but these are often significantly behind the times and don't acknowle…

Great comment, and does a good job of going deeper on my, as you say...terse summary. The truth is that most of what people do in the name of SOX is cargo culting other people's ideas of appropriate controls. In this case, you could give admin access to whoever you want. You just need reasonable documented controls around it.

The cargo culting is unfortunately too true. SOX/SOC reporting exists for a reason and it's actually pretty easy to get real value (which is the intent) out of it, as it formalizes what you should be doing anyway. It's a really good feeling when appropriate processes/controls reveal things that fell through the cracks and they get remediated. Prepping for and performing a successful audit needs to involve the company's subject matter experts from multiple departments. If only the CFO is involved early in the process, it makes life harder for the CTO, CISO, and CIO (or whoever they delegate to) later on.

Re: When Employees Use Software That IT Hasn’t Approved

#308
post #174

Earlier quoted context omitted.

>> It's like they get pet projects in their head from reading an article in a magazine and get locked into it. >It's not like that, it's often exactly that. And it usually is sold also from within from know-it-all primadonnas who want to climb the ladder. Or at least put something "spectacular" on their CV.

Or they just think “Tableau, Salesforce, data lakes, ERP, identity management, and "cloud" infrastructure each seem like useful tools if implemented smartly.”

Cute. We actually built a data lake (with Python and MySQL) and immediately found problems we weren't even aware of, like (as I mentioned above) people getting the same email multiple times in the same day.

When our sysadmin left, we migrated all our websites from leased hardware servers to cloud hosting and were able to use that head count to hire a developer instead, who has built great new web apps for staff and customers.

I understand the temptation to be cynical, but these really are useful tools. I say embrace change; it's fun.

Re: When Employees Use Software That IT Hasn’t Approved

#309

Earlier quoted context omitted.

If you're handing customer data to the developers, it's basically already leaked. Most companies limit who can examine things and get customer sign off first.

Let me reiterate: unless you're doing purely internal tooling, everything about how the software you're making should look and work is essentially sensitive customer data.

Actual customer data leaking is generally a legal problem. Your source code leaking is not.

Re: When Employees Use Software That IT Hasn’t Approved

#310
post #238
post #234

Earlier quoted context omitted.

We attempt to address this by making IT's annual bonus tied in part to our dev's project completion. It's not perfect, but the heart is in the right place. A big problem with this is that when we're dealing with limited manpower, we'd rather throw it at the easy issues than the hard ones, and ultimately get more things done.

Maybe create a 'time wasted' ticket system to help quantify employee hours wasted by IT roadblocks? It smells like it could be gamed heavily, but it might work better.

the same should then apply to "adopting the tool to the process" instead of "adopting the process to the tool" when a new technology is implemented but process and behavior are declared immutable.
Post reply on HN