Why can‘t I talk to IT?
If your IT request has ever been met with a blank stare or gales of laughter, this new column is for you
By Lisa Horwitz
In nearly 30 years as an instructor, systems engineer and technical architect, I’ve heard from many SAS® users that it can be a challenge to explain to the IT organization what SAS is and why it’s important. Why is this lack of communication a problem?
It often means that your requests never seem to get to the top of IT’s to-do list. Even worse, you can feel like IT is preventing you from getting your work done. “What do you mean I can’t have 20 years of claims data?” “So what if my job takes 10 hours to run!” “My job is important – why can’t it go to the top of the queue?” If you’ve ever said these things and were met with a blank stare or gales of laughter, you have experienced this problem firsthand.
Regrettably, it can feel as if you and IT are speaking two completely different languages, and the lack of a good cross-language dictionary can leave you feeling dissatisfied, angry and frustrated.
Mission-critical for IT
The biggest source of miscommunication stems from the difference in your roles. IT keeps the data center humming – the servers serving, the transactional data flowing, the databases growing, the applications running. The day-to-day operations of your company would come to a halt without IT’s diligence and attentiveness. “Mission-critical” to IT means recovering from a power outage or the failure of the infrastructure that runs the ATM or the call center.
Mission-critical for you
As SAS users, you keep the business humming by producing necessary reports, detecting fraud, ensuring that those who get a credit card offer are a good risk, confirming the safety of a new drug, identifying sales trends, predicting parts failures, and much more. “Mission-critical” to a SAS shop means that the CEO expects his dashboard to be current and the CFO is expecting that new forecast or risk model ASAP.
Which role is more important to the business?
We can debate which role is more important to the business all day long, but the reality is that both roles are essential. Better communication between the organizations will make everyone’s life better by helping to forge a relationship and develop an environment of mutual cooperation. Now, attaining a common language is going to take some work on both sides.
For the SAS folks, learning that “salt” isn’t just the white crystalline stuff you sprinkle on your food, but also an important means of increasing data and password security through encryption, is amusing. For the IT folks, learning that the SAS folks don’t know that, and that they probably aren’t too concerned about it as long as they can get to their data, is alarming. But the effort to find a common language will be worthwhile, if for no other reason than to reduce stress in the workplace.
In the IT Whisperer column, I’ll provide some interdisciplinary assistance in communicating with the IT organization and revealing the mysteries of SAS to them. Please let me hear from you about particularly difficult conversations you’ve had with IT and messages you’d like help conveying. In addition, let me know what’s worked well at your organization to form a bridge between the SAS users and IT, and I’ll highlight those successes here. Email me.
Tips for bridging the business-IT gap
Engage IT early.
You can’t do enterprise-level analytics without the help of IT. Business units can maintain independent analytic solutions for small projects, but true enterprise-level analytics requires coordination with IT, so bring them in early in the process.
Look for options that make IT comfortable.
If IT is a little hesitant about analytics it’s because they don’t want anything bringing down their systems, particularly business-critical ones. One option is to incorporate in-database analytics. It runs within the database in a way that doesn’t disrupt the day-to-day functioning of the database.
Develop a rapid prototyping model approach.
Start with a small part of the analytics problem, agree on a small milestone – and run with it. Then bring in the stakeholders and domain experts and have them validate it. Then do it again. Along the way, people begin to feel comfortable about what you’re doing.