IT and Functional Departments – Finding the Middle Ground

Today’s guest post is from Torey Guingrich, a Project Manager at Source One Management Services, who focuses on helping global companies drive greater value from their Procurement expenditures.

One of the challenges Procurement can face when working within the typical IT category is working on IT-related services that are used to support functional areas. Think of the marketing group or supply chain function; there are a number of different systems or software products that support those departments, but how clear is ownership of the solution between IT and the business group or function that the solution supports?

The answer to that question can vary across companies, across industries, and even across those within IT and the department utilizing the solution. Given this ambiguity, it is critical for Procurement to ensure representation from both and IT and the functional group for sourcing efforts that involve products and services that are not “purely IT”.

Does Procurement really need to be involved?

For many organizations, IT groups tend to work in a vacuum or keep their sourcing efforts separate from Procurement. While there are nuances that Procurement professionals need to be aware of and navigate within IT, there is clear value that Procurement brings to the table, especially when other functional departments are involved. Those in Procurement should be comfortable working with different areas with differing needs and finding a cohesive path forward. Procurement also brings market information (suppliers, price points, service levels) that IT may not be as focused on, but that could be critical to the overall solution. IT groups can at times limit themselves to certain suppliers for system or software solutions, but there may be alternate suppliers that easily integrate, or provide enough value to justify the effort required for working with disparate suppliers or systems. Procurement can bring that perspective forward and champion the needs of the business to balance the costs associated with IT change.

How do I know if something is “purely” IT or not?

When we look at organizations today, there tends to be a number of software and hardware suppliers that are categorized in spend data as “IT,” but fulfill a more functional or business need. When looking at spend and suppliers considered as IT, be sure to think through your organization’s end users and how the program or solution is being used by different groups. Marketing, HR, supply chain/logistics, and finance are all key functional areas that likely use some form of software to support their processes and should have a principal role in selection, whereas supplier selection for hosting or PCs and related consumables may be made more centrally within the IT area.

How do I get IT and functional departments to work together and come to a consensus?

When working with multiple stakeholder groups, no matter the departments involved, it is important to establish roles and responsibilities from the onset of the initiative. A key to working with these two groups is to consider what is most important to each group. Likely the functionality, ease of use, and flexibility of the solution will be top of mind for the functional department, whereas IT may be more focused on integration and hosting requirements, continuity with the company’s overall technology strategy, and licensing/purchasing models. Beyond IT and the functional area, discuss what other stakeholders may be affected or if other IT systems (and those who administer them) would be impacted downstream in the process. Focus the two (or more) groups on the goals for sourcing and what criteria is going to drive supplier selection – this will help to ensure that any critical issues or “deal-breakers” are identified and don’t come up later in the process. Each group will likely have their own set of requirements and criteria that need to be aligned and prioritized to ensure they are not in direct contrast with each other. Ask each group to look at their requirements and define the priority of each (e.g. rank as nice-to, prefer-to, or must-have) to ensure the core solution encompasses all must-have requirements.

Who ultimately makes the decision?

This is likely going to depend very heavily on your organization’s priority of functional and IT requirements. Ideally, Procurement can help bring these two groups together and drive to a decision point that all, including Procurement, can agree on. When the solution is business critical or the department relies heavily on the given product/service on a day to day basis, the business function is likely to be the lead in terms of making a decision, but IT will in any case need to validate that the solution will work from an infrastructure and support position.
While most may think of Procurement as a cost-reduction engine, we are uniquely positioned to enable relationships among different groups within the organization. Especially when working with software and hardware systems to meet business needs, it is critical to bring in IT stakeholders at the onset of the process to enable a more efficient and effective sourcing process that balances the needs of IT with the needs (and wants) of different functional areas.

Thanks, Torey!

Suffering from Prediction Mania?

Are you as addicted to the annual prediction explosion as you are to your morning double shot low fat no foam caramel latte with a sprinkle of cinnamon and two sprinkles of nutmeg? Can’t handle the withdrawal?

Then let the doctor give you Sourcing Innovation’s one and only original prediction (as he is joined by Mr. Smith in the prediction that all futurist predictions will be wrong), which, surprise and surprise, is the exact same prediction he gave you in 2013*, laid out in detail in this now classic five-part series! Enjoy!

  I: The CFO Gets Shocking Supply Chain News …

 II: The CEO Returns …

III: Bankruptcy?

 IV: How did it happen?

  V: The fault lies with …

And no, this is not cheating, since all most of the futurists do is recycle the same old predictions year after year, just like they recycle the same old trends, as exposed in detail in SI’s now classic Procurement Trend Expose series which revealed that most trends were old (or is that ancient) news or just continuing blues …

There’s Still No Spend Analysis Without the Slice ‘N’ Dice

SI originally ran this post 10, yes ten, years ago today, and nothing has changed. Regardless of how fancy that drill-down dashboard is, how many pre-canned reports come with the system, or how many sub-views you can create, if it’s still off of 1, that’s one, cube, it’s still limited in the value you will get. Moreover, this post is especially relevant because it reminds us of how BIQ changed the spend analysis game and that the individuals that spearheaded the company are game changers. This is particularly relevant because Eric Strovink, the founder and the person that has now changed the spend analysis game twice (first at Zeborg, now part of [IBM] Emptoris, before BIQ) is going to be launching a new analytics company this year, and chances are it won’t just be the same-old same-old rebranded Tableau or QlikView solution).

When I was in Boston, I was lucky enough to spend the better part of the day with Eric Strovink of BIQ, and have a few extended conversations with individuals at some of the local consulting firms that specialize in sourcing, and am now more than convinced that any tool that mandates a single cube, or makes it difficult to change the cube, is not a spend analysis tool, merely a spend data warehouse with built in canned reporting (and, if you’re really lucky, limited ad-hoc capabilities).

Not that there’s anything wrong with a centralized spend warehouse with a consistent view of your total spend, especially one that integrates multiple internal and external data sources and allows you to drill down and understand your spend at a detailed level. Of all the e-Sourcing software tools, it is the one most likely to make your CFO do backflips, especially if it has good reporting (and this is a big if – not all spend analysis tools on the market do), since it makes it really easy for the CFO to tell the CEO where the money is going and comply with all those pesky reporting requirements.

However, the value of such a tool is quite limited to you as a purchasing agent. Now, it’s true that the first time you’ll use it you’ll save big-time, especially if it’s the first time you have visibility into the majority of your spend, but the reality is that this is the only time you’ll see such significant savings. After you’ve identified all of the low hanging fruit identified by the single view provided to you by the system, analyzed each instance of over-spending, and taken corrective actions, you’ll find that you’ll be unable to identify additional savings and the system will simply function as a glorified data warehouse that you only use once a quarter to create those reports for your CFO and check that your teammates our buying off the negotiated contracts – something that you could do almost as well with your existing ERP system and a significantly cheaper Business Intelligence / OLAP tool like (SAP) Business Objects or (IBM) COGNOS and some grunt work.

Remember, I’m not saying that traditional spend analysis systems like those provided by e-Sourcing providers like (SAP Ariba) Procuri and (IBM) Emptoris are not without value – if you do not have a good, integrated, data warehouse that integrates your various accounting, purchasing, and inventory systems to provide you a single view of your spend or a good reporting system to produce all of the reports your CFO needs, then you’ll find these systems very valuable. However, it’s important that you understand that the primary value of these systems is in the total spend visibility they provide from a financial viewpoint, not the spend analysis capability you really require to identify potential overspending and cut-costs, because you’ll only be able to do this once – thanks to the single organizational view they are built on. (In other words, you’ll save big when you fist implement the system but future savings will be limited to your capability to quickly catch and stop maverick spend.) So, if you need a system to consolidate your spend data, produce the tedious reports required by all of the new financial reporting requirements, and give you some basic across-the-board spend visibility, or, more importantly, you need a spend data warehouse that integrates with the rest of your e-Sourcing suite, be sure to check these systems out – but understand what they are really worth to you before you sign the check.

In order to help you understand where these systems fail in true spend-analysis, why you need to be able to dynamically create multiple cubes on the fly which support dynamic dimensions, meta-aggregation, cross-dimensional roll-ups, and even federated data sets, I’m happy to inform you that Eric Strovink has agreed to co-author a series of posts outlining what real spend analysis is, how it differs from basic spend visibility, what it does for you, and why you need to get there.

Eric Strovink was actually kind enough to contribute two insightful series to Sourcing Innovation. Here are the links for your reference.

I: The Value Curve
II: The Psychology of Analysis
III: Common Sense Cleansing
IV: Defining “Analysis”
V: New Horizons I
VI: New Horizons II

I: It’s the Analysis, Stupid
II: Why Data Analysis is Avoided
III: Crosstabs Aren’t Analysis
IV: User-Defined Measures, Part I
V: User-Defined Measures, Part II

Process Transformation: How Do You Get it Right? Part VI

Two weeks ago, we talked about how to drive technological advances, because it’s one of the critical three T’s of Supply Management success (with the other two being talent and transition to better processes). But technological advancement is not enough if your processes, to be blunt, outright suck harder than a Hoover. That’s why, as the Big C’s say, you will need to achieve some “process transformation” if you ever want to become best in class (and why each of these Big C’s claim to have the best advice [for a price] to help you along your journey).

However, as we outlined in detail in our first post last week, it’s very difficult to tell if any of the Big C’s have WHAT you need when, for example, the difference between the four-step framework promoted by one of these C’s (PwC, although SI could have picked any of them … and we do seriously mean any one of them) and four of the first eight random mission statements generated by the mission statement generator at (which is almost as good as the now defunct Dilbert mission statement generator) is pretty hard to discern!

Then, as outlined in our second post, we made it clear that what you really need is a simple process that starts with understanding where you are now, moves on to figuring out where you want to be, creates a plan to get there, and, finally, executes the plan. Then we began our series in earnest by outlining what is involved in understanding where you are now (which is more involved than you might think), which often doesn’t require a team of 10K-a-day consultants, continued on by specifying how you go about figuring out where you want to be (which is often more difficult than one may think), discussed how you how you put together the plan, and then, finally, in our last post focussed on execution — which is always harder than you think.

So where does this leave us? Frankly, with a focus on Adoption, Adoption, Adoption, Adoption. Just like Ballmer used to go hysterical for developers (even though anyone familiar with Brooks’ work on software engineering and The Mythical Man-Month knows that sometimes less is more, especially when you have top talent), you need to get hystical about adoption. If the software is only used by 25% of the people, and even these people aren’t using it all the time, it’s not worth whatever deal you got on it.

And adoption needs to start day one. The users who need to use it everyday need to be involved in the plan from inception through execution. From day one, the cross-functional team needs to include a representative of every user group who will make sure key processes are supported, usability is high, and concerns are met — and if necessary, ensure you sacrifice the few “power features” that only a few will use in favour of the “adoption features” that will ensure a mass roll-out. (Remember, for highly specialized needs, there’s always a point-based best-of-breed solution out there you can get for the power users. And sometimes the ROI from getting two solutions [even at twice the cost] outweighs the ROI from a single solution. Remember, ROI is only X/4 with a 25% adoption rate. With 100% adoption, it’s X, so even if you have to pay 2X for 2 solutions … you still get twice the return.)

So focus on adoption during your process transformation efforts and you will truly achieve process transformation and the results you desire. Otherwise …