CFO magazine has an online article titled "A Defining Moment" that caught my attention because it talks about how vendors of governance, risk, and compliance (GRC) solutions are smarting from charges that they allowed their customers to be blindsided by the risks that have resulted in their businesses failing.  In the article they quote someone from Forrester Research as saying, "Some blame vendors for skimping on risk and governance software in favor of more easily salable compliance tools.  The risk function is something software vendors didn't build out very well…"  Later on we see another statement: "But the biggest question of all remains whether and to what degree software can automate and augment the many business processes that lie at the heart of governance, risk, and compliance."  What really gets me is how both of these seem to show a basic misunderstanding of risk.  Risk management (like governance) is a human-driven activity that no software solution can provide; software can only facilitate risk management activities.  After all, who is ultimately responsible for risk management?  The vendor?  Of course not!  It's management.  Every organization, using the tools at its disposal, is obligated to identify risks to the company and then decide whether to accept, avoid, control, or transfer those risks based on the company's risk tolerance.  In other words, management owns the risk management process.  It cannot be outsourced, nor can it be performed by a vendor.

I also want to address the statement about how vendors are focusing on selling compliance solutions simply because they are an easier sell.  Note to Forrester: they're easier precisely because that's where automation is the most appropriate!  Any auditor will tell you that it's preferable to automate as many controls as possible (and where it makes sense), which falls under the Compliance "leg" of GRC.  However it's a different thing entirely to say the same for Governance or Risk.  These cannot be automated in the same way that Compliance can.   I would like to know how the folks at Forrester would suggest that vendors do this though.  It's really easy for someone at Forrester or Gartner to slam somebody for not doing this or that, yet when it comes to discussing alternatives they either offer vague ideas or simply remain silent, expecting the rest of us "unwashed masses" to take their word for it and wait for their next pontification.

Regarding the second statement, it answers its own supposed question about whether software can automate and augment the many business processes that lie at the heart of governance, risk, and compliance.  Note to John Edwards, the author of the article: this is exactly what software is supposed to do!  Software tools automate and augment the business processes.  The process owners and other stakeholders then use the tools to manage enterprise risk and compliance, which in turn supports the overall state of governance.

Finally, the fact that no one has really defined what exactly "GRC" means doesn't help matters much either, so how about we start with that?  It should be fun to watch.

No related articles.

Like medieval kings promoting cross-kingdom marriages to support peace and prosperity (or at least tightening up alliances), we hope this latest nuptial bodes well for ties between the two organizations.

No related articles.

Convergence continues to gain traction

Regulatory pressures coupled with the need for cost-saving efficiencies drives tighter operational alignment between physical and logical security. We expect to see an increase in attention given to this matter by the various professional organizations serving both sides of this equation as the overlap in their member communities increases with folks gaining certifications to bolster their resumes for a shaky job market.

Discussions with clients and colleagues late in 2008 lead us to believe that this charge could likely be driven by the physical security side looking to create or add value by attaching to information security processes, projects, and opportunities. The market will follow suit as physical security consulting, staff augmentation (such as guard force management) and VARs see a margin squeeze on the horizon and the nimblest either partner or acquire deeper information security expertise. We think that with pressure on both the buy and sell side,  the broader market will finally drive this opportunity to bear some real fruit.

We also feel that certain folks hawking PSIM (Physical Security Information Management) platforms and other specialized technologies are doing a disservice to this trend and will be perceived as such. Convergence is a critical step in ending the “balkanization” of the security and compliance industry across job roles and holds the promise of great things for organizations that can pull it off successfully. Look for other convergence opportunities as privacy, audit, and legal find alignment beneficial to their organizations.

With fewer People, it comes down to Process over Technology

Due to budget constraints, there is a renewed focus on efficiency and quality instead of the new shiny technology that takes training and headcount to manage.

“Efficiency is doing things right; effectiveness is doing the right things.”

-Peter F. Drucker

So much of the past few years of sales and marketing efforts by companies (both product and services) have focused on plugging holes with technology.  Typically, this involved combating the next new threat with an appliance, or worse, a feature looking for a product. In 2009, this “boogeyman approach” takes a backseat to doing things right in the name of efficiency. Look for an uptick in tools that support the security and audit processes of the organization as opposed to those that block a particular threat.

The Year of the Pilot

Many organizations will launch prolonged pilot programs and dabble in a few technologies but large scale deals and deployments will be far and few between. As larger enterprises continue to reduce headcount, look for shrinkage in license counts for those companies with large renewals this year. Vendors that worked longer term deals through 2008 only delay the pain, as we see this issue lasting into 2010 since rehiring is a lagging indicator for an economic turnaround and license true-ups lag even further behind.

SEs over Professional Services

In 2008, Symantec eviscerated its professional service team, opting instead to build a staff augmentation model euphemistically called “Residency Services”. This leaves a gaping void to be filled for troubleshooting the current install-base, as well as standing up new installations. Look for savvy sales teams to leverage the talent still available in their pools of SEs.

With fewer large deals, sales will try to reap additional dollars out of existing clients. This will cause clients to dig deep for unrealized value on their existing installations. Professional services dollars will not be spent to find this value, instead, the SEs will be dropped into the line of fire to “save the account” and provide value enhancement through “health checks” and other customer satisfaction programs. This places a greater burden on the SE organizations and makes being an SE an even tougher job with increased travel and longer time away from home.

Further supporting this trend, Guidance Software restructured its Professional Services and Pre-Sales Engineering for 2009 by collapsing the two functions nationwide and splitting the country into two regions. This will create conflict as consultants learn how to support sales and SEs are fielded for longer engagements (most Guidance deals come with at least 1-2 weeks of services) and need to learn the patience and bedside manner needed for this type of work.

Additionally, many of the downsized professional services staffs have deep technical expertise that hasn’t been overlooked by the channel. Look for the VARs to build up their bench strength by cherry-picking the best and brightest vendor talent as they become available.

Channel opportunities change

Symantec’s restructuring of their Professional Services, along with the new Residency Services program, has created problems as they learn how to properly write terms for and manage expectations on this type of business. While staff augmentation is usually well positioned in the face of economic uncertainty, sales forces for the major players also have watched a lot of talent pour out of their companies, undermining confidence in their ability to deliver.

Additionally, more deals and clients will go direct, bypassing the channel (McAfee may handle this better though), as vendors try to lock in margins and clients seek out economies of scale in purchasing strength.

Smart VARs will look to exploit this “perfect storm” with new, higher value offerings and will be able to take advantage of displaced professional services labor let go by their vendor partners. The savvy VARs that picked up discarded top notch professional services talent will become the “go to resource” for local vendor sales teams. Look for these VARs to make up lost license revenue by writing services-only business on deals where the vendor takes down the licensing revenue. There will be price pressure on these VARs however, as in some markets; they will be forced to compete on price and ease of doing business since their bench of expertise will now be in direct conflict with “free” services offered by vendor SEs happy to have a job. either way, the buyer wins on this deal by squeezing the margins out of both product and services.

Continued market consolidation

We will continue to see smaller companies get acquired as valuations drop in the wake of economic turmoil. IPOs remain far and few between (reda as: non-existent) giving start-ups fewer opportunities for exit and with cash flow as king, many “feature only plays” die on the vine. This will play havoc with clients and VARs alike as their portfolios of products will be in constant flux. Look for both to work to build relationships and strategies to help minimize the impact.

Some vendors will look appetizing as their stocks falter on poor execution (look at Access Data’s failed bid for Guidance as an example). For larger players, an alternative will be the shedding or spin out of various business lines into independent entities (as Nokia and RSA did in 2008).

Security as a service expands beyond monitoring

Our only technology specific prediction for the year is: As web 2.0 technologies become more commonplace and products become less appealing, look for organizations to begin adopting new “security as a service” (the other SaaS) offerings. These new service lines extend beyond the typical MSSP role of monitoring and log collection to take on operational issues such as the process opportunities we alluded to earlier. This charge will likely be led with smaller companies extending the already rich “IT as web-app” charge by going beyond help desk ticketing and looking to explore compliance and security cost reductions in operations.

Renewed focus on operations

For the latter part of 2008, we spent a lot of energy looking at how the market was behaving. In a crazy market, it was to be expected. While more important to the vendors and VARs, we will be shifting our focus back to how the professionals in our community are getting their jobs done and how to improve the state of the art.

Thank you all for a wonderful 2008, we look forward to your continued insights and conversations in 2009.

No related articles.

I think the Microsoft/RSA announcement gives DLP, in general, some added credibility.  I don’t see this having a great competitive impact in the market in the short run, but in the long run, it shows an attempt to integrate existing technology with newer DLP functionality to address the growing concern of data loss.  It appears now more than ever that some level/aspect of DLP may be built into some applications.  I’ve heard some predict that DLP will go by the way-side as all apps include data protection capabilities, but I still think that the DLP products will play a role in monitoring the gateway, managing policies, reporting, etc.

What I think is funny is that over the few weeks leading up to this announcement, I had an increase in Microsoft employees requesting information.  In hindsight, this was a clear indication that something was brewing.

More interesting now is the fact that in the past few days there have been a handful of informational requests from CA employees.  Perhaps another acquisition at CA? If I were some of the smaller DLP players in this economy, I may want to cash out now rather than face potentially a few years of uphill battle for revenue.

On the economics of our time, from talking to others selling this technology, the only way they’ve been able to sell through Nov and Dec is with huge discounts.

No related articles.

No related articles.

Arcsight Google Ad 1

Arcsight Google Ad 2

High Tower Software was officially founded in 1999 by former JPL researcher, Dr. Ursula Schwuttke. The technology High Tower employed was originally developed at NASA for high-volume data analysis and in its original incarnation, was used to dig into data from the deep space probes Voyager and Galileo.

Not wanting to miss the SIEM (at the time, just SIM) market boat, High Tower narrowed their focus and dove headfirst into the murky waters of the information security space. While focus is a definite positive in start-ups, was it the choice of this highly competitive market that planted the seed for High Tower’s demise?

Their first round of funding in July of 1998 came from Inroads Capital Partners, Merrill Lynch Capital (acquired by GE in 2007), Hallador Venture Partners and the J.F. Shea Company. The approximately $1.9 million was used to jumpstart the new company and transform the licensed technology into something more commercially viable over the next 18 months.

In the fall of 2000, they took on another $10 million in a B round led by Liberty Partners, adding Kinship Partners to the mix of previous investors: Merrill Lynch, J.F. Shea Co., Inroads Capital Partners, Hallador Venture Partners. This time, the money was earmarked to expand sales and marketing efforts of the maturing technology. At this point, High tower was still focused on their original data analytics plan, even drawing on their roots by securing Intelsat as a client and using them in an early case study.

By early 2002, High Tower had started dabbling in the networks operations realm by offering their TowerView product as a NOC tool, all while also maintaining their original vision of providing deep data analytics for broader business applications in retail, healthcare, and finance. In 2003, they launched a version of TowerView specifically targeting the security market.

Barely a year later, in October of 2003, they closed on a $6 million Series C round of funding. Once again, Liberty Partners led the round, and earlier investors Inroads Capital Partners LP and Hallador joined the fray, picking up the Falcon Fund along the way. In 2005, High Tower scored their fourth round of $4.3 million and did a bit of rebranding, positioning themselves squarely in the security space for 2006.

Later, in the fall of 2006, High Tower squeezed another $6 million out of Liberty Partners and InRoad Capital Partners in yet another round. By April of 2007, Cleve Adams, formerly of WebSense was brought in as the new CEO and President to restart/turnaround the firm, bringing with him a dozen of his WebSense colleagues to aid in the effort.

While they continued winning accolades and being a prominent fixture on the trade show and speaking circuits, the new team was unable to make good on the vision of a turnaround. High Tower abruptly closed its doors last week. Approximately, 34 employees lost their jobs and the technology platform is currently up for sale. We are not sure at this time if the original NASA licensing deal is part of the sale.

So, was the focus ill-timed or was it something simpler like expense management? Despite taking down large amounts of cash over the years, was it simply a matter of not switching their focus early enough?  Was their burn rate not able to be sustained in today’s capital markets? Regardless of the cause, I’m sure the channel and consulting partners they continued to sign up (some as early a few weeks prior to the shutdown) are feeling the sting.

No related articles.

After a few calls, into Symantec, their channel partners, and the financial community, we learned that this was not a new strategy at all. It seems that Big yellow has always allowed their bigger customers to go direct, even if a channel partner registered the deal and brought it to the table. While this seems to "poison the channel", as Shimel said, I have been assured that in most (but not all cases) if the partner registers the deal, but the customer goes direct, then the VAR still gets a 'kickback' on the deal from Symantec. Now, I don't know if this common amongst other vendors, but this does show another leverage point for the buyer. If you can save a few points on the deal by going direct with Symantec, but a VAR did the legwork, then you know a bit of the deal will flow back to them. This is a clear indicator that a little more can be squeezed out of the deal to your advantage. It also means that an interesting dynamic can be created by pitting Symantec against their own channel for the business. In short, the VARs need to work very hard to put the Value back in their name.

Symantec's COO, Enrique Salem's response to the firestorm, forwarded to us by our concerned colleagues,  is pasted below the fold.

Also, the PDF of Salem's original comments to Wall Street , quoted int eh above mentioned articles, can be found here. Page 25 seems to be where all of this noise started.

From: Symantec Corporation

Sent: Wednesday, July 16, 2008 4:54 PM

To: Partner

Subject: A Message from Symantec's Chief Operating Officer Enrique Salem July 16, 2008

Dear Partner,You may have seen some recent media coverage around Symantec and our partner community. I want to ensure you have the most accurate information on our current channel strategy, correct some of the current misconceptions and reassure you of our dedication to supporting the channel.Symantec continues to be a channel-led company, with the majority of our business flowing through you, our partners. We are deeply committed to providing you with market leading products, the best quality service and support, and programs to help drive profitability and improve your experience with Symantec.There has been no shift in our channel strategy. It is important to remember that Symantec's customers have always had the opportunity to buy direct in all of our segments. This is not new. However, as a result of feedback from our partner community that we provide clearer rules of engagement, we have recently clarified with our partners that only our top named account customers have the choice to take their business direct. We have not made any compensation, discount or program changes that would incent a customer one way or the other. Business outside this list is to be fulfilled 100% by our partners. This provides clear guidance, and a significant opportunity for partners to drive our business in the Enterprise and Mid-market space.I would also like to reiterate that we have not moved away from a two-tier distribution strategy. We continue to maintain a two-tier distribution strategy and, like many other vendors, we are now allowing our single tier partners to fulfill complex enterprise contracts directly with Symantec to streamline the process for our customers and partners.Finally, we are not changing our strategy to take SMB renewals away from our partners. Rather, we have invested in automation that will drive efficiencies for the channel in how we renew customers in our SMB customer segment. Our 60-day renewal notice to our customers encourages the customer to renew, with their partner, and provides information on the reseller of record. At 30 days, we remind the customer to renew – either through their partner, or online. By prompting customers to renew, and providing information on the originating partner, we believe this will increase your profitability and help drive more revenue for you in this space.I appreciate your on-going support of Symantec. If you have any questions or concerns, please contact your Symantec sales manager or send an email to partnerus@symantec.com.
Sincerely,

Enrique Salem
Chief Operating Officer
Symantec Corporation

No related articles.

As for more descriptive rules and standards (PCI, HIPAA, FISMA, FFIEC, etc.), understanding how compliance and information security fit together and within the bigger GRC picture can help you reduce the compliance burden—particularly if your company is covered by multiple overlapping regulations.

Consider two scenarios:

1. Because many compliance implementations are project oriented and deadline driven, security managers focused on meeting one regulation or framework fail to see the overlap between their project and other security efforts.
2. PCI and HIPAA pains are compounded when covered information is not compartmentalized and security managers attempt to apply stringent control requirements to complex and distributed systems.

Both approaches are wildly inefficient. At first glance, it might also seem that you can’t resolve one problem without aggravating the other by either compartmentalizing or universalizing security controls. This is where it’s very helpful to understand the difference between risk management and compliance.

Enterprise information protection is fundamentally a risk management challenge. Regulations like PCI, etc., are not comprehensive in this regard since they cover limited types of information with fairly specific requirements that are, truth be told, reactive to threats and vulnerabilities identified in specific (past) security incidents. A risk management approach to security should be more comprehensive in both regards.

That said, compliance provides a handy excuse to codify sound security management processes in a limited way—test projects of a sort. In fact, limiting the initial implementation scope[1] can have several benefits beyond that of meeting compliance deadlines.

Executives like compliance. They fund compliance—often under less scrutiny than plain ole IT projects. I know of at least one IT manager who got an entire SAP implementation funded under SOX compliance. While most of us can’t expect to get such largesse, wrapping an ISO 27001/27002 pilot project in a PCI banner (for example) might be more readily attainable.

This approach would benefit the PCI efforts, since ISO 27001 is the sort of security management framework that PCI could really use. Meanwhile, implementation of the 27002 control standard would hit the PCI requirements and more. The project itself would produce demonstrable results useful for supporting budgetary requests for standardized control roll-outs to systems beyond PCI’s scope. And leveraging the managerial and technical lessons learned during the PCI implementation should provide a compelling argument for efficiency in scope expansion.

This is just one example. Any robust framework for security management and control (ISO, CobiT, NIST/FIPS) coupled with any security mandate (PCI, HIPAA, FFIEC, GLB) could effectively follow the same model.

Zooming up a conceptual level, what we’re really talking about here is standardizing and simplifying information security practices at an enterprise level—a GRC argument, sparked a compliance mandate. Security risk abatement is just one part of the picture.

I mentioned earlier that compliance is an incomplete approach to security, but various security rules overlap and all of them can be mapped [2] as subsets of ISO 2700x, CobiT, or NIST frameworks—collectively comprising a more adequate security approach.

Once you begin measuring other project-driven security projects against a proven, robust management and control standard, you’ll almost certainly discover gaps and inefficiencies that weren’t apparent in those projects’ siloed environments. That’s a risk management benefit. The governance angle is cost savings, consistent compliance, and reduction of redundancy and inconsistency. These go beyond IT controls to include audit processes, security management, and software investments.

ISO, CobiT, etc. can also be (and have been) mapped to enterprise risk management frameworks, maturity models, and project management best practices. Or, anyway, CobiT has. But since ISO is mapped to CobiT and CobiT is mapped to OCTAVE, CMMI, the PMBOK, etc., you can map the maps, do a bit of double checking by the source documents, and generate an ISO-to-OCTAVE map of your own.

Finally, if you want to get really ambitious (or possibly make enemies in high places), you can tie the whole enchilada to an IT investment management framework, like the one published (PDF) by the GAO. Your tax dollars at work.

Now, you might be feeling that very little of this has anything to do with why the bloggers (Remember the bloggers? This is about the bloggers.) are criticizing GRC. And that brings us to the subjects of vendors, software, and marketing.

The security bloggers’ argument against GRC is really an argument against a relatively small spectrum of GRC that has shined on their work through the vendor marketing prism. But writing off the useful concepts of GRC because it’s misrepresented by overzealous vendors is like hating the sun because it won’t light your cigarette. …Actually, it’s more like hating the sun because you mistakenly think it exists to light your cigarette, but doesn’t.

GRC is not a tool. That said, Christopher Hoff’s observation that “GRC appears to be a way to sell more products and services under a fancy new name to address problems rather than evaluate and potentially change the way in which we solve them” has some merit.

From the vendor perspective, GRC represents a great new way to sell solution offerings to senior management having to make much of a development investment. Seldom in the annals of business software sales have vendors been able to tap such rich aquifer of fear, uncertainty, doubt. You bet they’re going for it.

But GRC didn’t start with the vendors and it doesn’t end there, either.  The vendor reflection of GRC is simply a reflection. A more accurate reflection lives in regulations and standards. However, GRC itself is the business of running a business, and we should always be wary of letting vendors define that for us.

Related articles:

1. The Tao of Security or: How I learned to stop worrying and love GRC (part 1 of 2) It seems a few infosec bloggers here, here here (read...

As a disclaimer, I’ll admit I like the term GRC, despite its slick acronimity and marketing smack. It’s a rare acronym that means more than the sum of its interrelated parts. Take out any component and the other two are degraded. Risk management and compliance provide focus for governance. Governance and risk management provide relevance for compliance. Compliance and governance provide oversight for risk management. Three great things that go great together—or should, anyway.

What do these components entail? Governance is the whole of oversight structures and activities that shape business (and IT) activities. Risk management is a subset of governance that weights and prioritizes business activities according to their impact or value in marginalizing negative contingencies, per their relationship to defined business goals. Compliance should be a subset of governance efforts that meet specific criteria of regulations, policies, and laws.[1]  Naturally, compliance and risk management overlap (and both overlap governance); however, risk management generally addresses a broader scope of business and IT efforts than mere compliance requires.

At least one of Brightfly’s members likes to tack an S for security onto GRC. His logic is that security is at least as big an issue as compliance, so it deserves equal strategic consideration. While I see his point, I feel it’s like saying the earth has eight continents—seven land, plus one water, No doubt, security is a massive concern, but its nature is pervasive, not inclusive.

Moreover, and to the fallacy that security is equivalent to compliance, information security is pervasive in just one aspect of governance, risk management, and compliance. Information is, after all, only one type of business asset that GRC should address (note that COSO and the SOX audit standards imply security only obliquely, via information integrity requirements). Even under the lesser umbrella of information GRC, many concerns—such as technology investment management, communications, e-discovery and content management, and business intelligence—only tangentially consider security goals.[2]

Understanding how security fits in the big picture, but is not itself the big picture, is critical to successful enterprise security management. Security should be everywhere—explicit in every new project plan; inherent in the concept of every business process; integral to every risk consideration, and implicit in every governance realm. But to get the executive and managerial support that business integration requires, we must give up the notion of security as its own goal and champion it in terms of (can you guess?) business governance, risk management, and compliance.

Tying security to the business had benefits beyond propagation, however. From a conventional security perspective, risk management is seen as an output of security programs: more security equals less risk.

By contrast, the business perspective defines risk as an input: risk thresholds define control efforts and audit scope.

If you’ve read the blog threads cited above, you’ve seen references to the embittered notion that compliance actually impedes “real” security by forcing security managers to focus on hitting audit targets instead of setting their own priorities. Audits, however, should adhere to business risk.

SOX auditors, for example, care about security because it ensures confidentiality, integrity, and of financial information. But the scope of SOX audits is defined—even limited—by what the business defines as material. Security audits, insofar as they’re implied by SOX, should be subject to the same scoping.

The PCAOB’s Audit Standard 5 (AS-5) is fairly explicit on this matter. Management, not auditors, defines risk and materiality, and auditors are advised to trust managerial judgment. AS-5 is actually largely a regulatory response to managerial complaints that external auditors were auditing too much (and charging too much) to review controls that had no material impact.

Managers, including security managers, can use AS-5′s risk management principles to give pushback to both internal and external auditors on audit scope. Since SOX defines materiality as component of compliance, compliance priorities should never force security managers to favor irrelevant efforts.

Of course, SOX is just one fairly prescriptive law, although the same risk management scoping can general apply to any prescriptive guidance, as well as IT frameworks and standards like the ISO 27000 series, CobiT, and/or the US government’s NIST 800-series. Meanwhile, as you’re probably painfully aware, banking, health insurance managers, retail, government agencies, and other industries are also subject to more descriptive rules and standards, such as PCI, HIPAA, FISMA, and FFIEC.[3] Understanding the bigger GRC picture can also help reduce the burden of these efforts, particularly when a company is covered by multiple security regulations.

More on this tomorrow.

—

Footnotes

1. Compliance pursued blindly isn’t a defensible priority of risk management.
2. Or not. An increasing focus on process-oriented IT—technology defined and valuated only in terms of the business processes it supports—is causing some of us to reevaluate whether information security should always be managed only as as a component of other processes. If you’ve seen recent articles or blog chatter about the “death of infosec” (a concept understandably abhorrent to many infosec practitioners) that argument reflects this shifting concept of what security is: an attribute of processes or a process unto itself.This is part of why it’s so important not to define GRC as information security. The chaos and gappiness of, security as we know it today, is a transient, reactionary response to companies’ frenzied realization that they should have been protecting information all along. Most efforts in dedicated security practices now focus on remediation: instilling security in existing legacy applications, systems, and processes that lacked them before. We have a long way to go; however, the foreseeable evolution of security practices is less catch up and better integration. Not so much killing security, but rather bringing it back from Coventry.
3. Of course, some of these are nearly the same thing. HIPAA, FISMA, and FFIEC requirements all refer to the NIST information security guidelines. In terms of information security, the technical requirements for all are similar, although the regulations cover different types of information. The new NIST Special Publication 800-66 (PDF) handily parses and compares the provisions of HIPAA, FISMA, and NIST publications.The PCI Data Security Standard (PCI DSS) is effectively a subset of the ISO 27002 standard; which, while less specific than NIST in terms of technical requirements, sticks to common security concepts.

Related articles:

1. The Tao of Security or: How I learned to stop worrying and love GRC (part 2 of 2) (Continued from Part 1.) The same risk management principles that...

Purchasing managers commonly pit multiple vendors against each other in a bid process to  improve leverage on negotiation points. This practice can also generate animosity between vendors, however, making them reluctant to work together to resolve customer issues. How can you facilitate the transition from competition to cooperation?

I faced this problem at a previous employer, where I was working with an internal team to create a more consistent vendor management system within our department. Our primary goals were to simplify the procurement process used to engage our vendors and create a standard procedure that would level the playing field and reward good performance. We quickly realized that achieving consensus among all of the vendors would be a primary success factor in our process.

After several internal conversations, we invited the vendors we currently had agreements with to sit around the table to discuss project objectives. Most of the vendors confessed they had never been asked to sit in the same room as their competition and discuss how to improve their clients’ process. Although some vendors were reluctant, the majority eventually agreed to participate for benefits of being included in the process.

We drove the process, starting by establishing acceptable parameters for participation in the round-table process. Some of these parameters included:

• Agreement by all participants to treat each other with respect
• Encouraging all participants to contribute to the process
• Discouraging negative statements and/or criticism of any information offered

We had several observations from this process including aggressive participants and cautious sharing. Some vendors were more open to participating while others were obviously uncomfortable and reluctant to share. There were a few “natural leaders” who asked a lot of questions and offered constructive comments. Several points were debated via some heated exchanges (no surprise here!). This was obviously a unique experience for the majority of the vendors.

We learned several things during this process. When vendors accept the challenge and rise to the occasion, they offer valuable input. Unfortunately, some vendors confuse competitive advantage with marketing hype, and some are trained not to share anything with their competition. The successful vendors put their client’s need above their own prejudices and fear of losing market share. When vendors cooperate, their clients benefit and get improved service.

Ultimately, both the company and the vendors realized real benefits from the process, including:

• The vendors open to participating and contributing to the discussions (there were a few vendors who were more spectators than participants) ended up getting more of our business going forward. They were more flexible and accepting of our terms and beat their competition by out-performing them.
• We dramatically reduced the time necessary for acquiring services from the vendors. We incorporated several changes streamlining the process.
• We established renewed relationships with the vendors as we raised expectations and rewarded high performers with more business.
• We reduced unsolicited calls to IT Managers by establishing a single point of vendor contacts.
• We instigated a tiered approach to our procurement process which favors vendors who respond quicker with valued resources.

Bringing the vendors together to participate in a structured session resulted in improved service, reduced risk of poor vendor performance, and rewarded vendors who remain in compliance with our procurement process.

I would be interested to hear about other experiences working with vendors in a similar manner.

No related articles.