spk-logo-white-text-short2
0%
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Taking IT Out of Corporate IT … A Response

Written by Chris McHale
Published on October 13, 2011

take IT outside of corporate ITThere were quite a lot of comments on this site and other sites on the original post — all by IT professionals, and almost all negative. The comments were interesting, but quite one-sided. Many people thought the article was suggesting dropping a figurative bomb on the corporate IT department and making every department fend for itself. Obviously, that won’t work.

Technology is not only a necessity for today’s companies, but it is undoubtedly a differentiator. Information technology management is absolutely critical to the success of businesses. But corporate IT doesn’t necessarily get good grades from those using its services. Why not? There are a myriad of answers, but I’ll focus on one—if IT is too centralized, it can’t effectively serve the organization. The more deeply you understand the daily business of a department, the better service you provide.

This isn’t a surprise to anyone; after all, governments and organizations endlessly battle over how much power should reside at the grassroots level, and how much power should reside with the centralized group. There are arguments on both sides. But in the end, isn’t the best answer some kind of hybrid solution? So… I’d like to paint a picture of a different IT support model. And it is one that involves taking some of IT out of corporate IT.

You still need a corporate IT department that reports to a CXO. It focuses on corporate issues—setting policies, governance, shared infrastructure, shared networking and communications, data protection, business continuity, compliance, shared supplier relationships, and so on. It takes care of the IT things that affect everyone or that should be centralized because the centralization saves the company a bunch of money.

One size does not fit all. Each organization would need a slightly different flavor of this depending on its culture, size, industry, or geography. The trick is to establish specifically what this group is responsible for, and what it should hand over to… let’s call it the “department technology group.”

This group is comprised of skilled IT people, but with a twist. They also have an IN DEPTH understanding of the business of the department. So, if it’s a finance department, these technologists might have been accountants or financial analysts before moving into technology. Or, if it’s an engineering department, the technologists might have been software developers or electrical engineers before moving into information technology. Or, they’ve spent a lot of time getting to know the day-to-day technology needs of that group of people. They sit in that department with everyone they’re supporting. They attend department meetings. You get the picture. And yes, they report to someone in that department and that department pays their bills. Because they truly understand the department’s business, they provide phenomenal technology assistance that saves people time, money and improves the quality of the work.

“Wait, but won’t the department technology group be completely at odds with central IT. Won’t the two groups fight or, worse, ignore each other?” you ask. Not if you set it up the right way. Department tech will have to abide by policies established by central IT—security requirements, compliance requirements, use of shared infrastructure, etc. But department tech has a voice; if someone in department tech thinks, for example, that a security requirement will adversely impact his department’s business and isn’t necessary, he can intelligently represent the department’s needs because he speaks both languages. The business units now have technologists looking out for their specific interests but who also understand what central IT is trying to accomplish.

I could go on, but I’m interested in what you all think about this model. Some companies already have it in place. Does yours? How well does it work?

Chris McHale
VP, Account Services

Latest White Papers

10 AI Use Cases: Accelerating Automotive Embedded Development

10 AI Use Cases: Accelerating Automotive Embedded Development

Software-defined and electric vehicles are only increasing as automotive technology advances. As these features grow, automakers must adapt. Manufacturing a car is not the same as it was years ago. This eBook explores how AI can be used in the automotive development...

Related Resources

Why Late-Stage Changes Are Killing Your Time to Market

Why Late-Stage Changes Are Killing Your Time to Market

Key Takeaways Late-stage changes get expensive fast: The farther a problem travels through design, testing, and manufacturing, the more time, cost, and rework it creates. Disconnected systems and weak traceability are major causes: When requirements, design, software,...

5 Ways to Reduce Engineering Cycle Time Without Adding Headcount

5 Ways to Reduce Engineering Cycle Time Without Adding Headcount

Key takeaways Faster engineering does not always require more headcount: Disconnected systems, manual handoffs, rework, and poor visibility often create more delays than a lack of engineering capacity. A digital thread can eliminate major sources of wasted time:...

The Engineering Digital Thread Playbook

The Engineering Digital Thread Playbook

In many organizations, systems operate independently, creating a large visibility problem. A digital thread addresses this by creating a connected flow of product information across the lifecycle. This playbook explains why engineering visibility matters, and how...