Wednesday, 22 February 2017

Redefining BIG for Outcome-based Procurement

Kelly Barner, Managing Director of Buyers Meeting Point explains the ever-evolving role of procurement, how it has redefined the value of supplier relations and what it means to be BIG.

If procurement has learned anything from our evolution up to this point, it is that scale is often the enemy of strategy. When we give in to the pressure or the desire to take a transactional approach for the sake of covering more ground in less time, we sacrifice the ability to make optimal decisions that draw maximum value from our effort. It is simply impossible to be sprawling and agile at the same time.

In our efforts to become more strategic, we have learned to choose our projects wisely, to follow an approach tailored to the situation at hand, and to think through every step before we take it. When procurement presents our results to the leadership team, it is no longer enough to talk about straight numbers: savings, spend, transactions, and suppliers. Visionary executives want to be informed about relevant nuances: building knowledge transfer bridges internally and creating competitive advantage externally.

Under the old transactional procurement model, the person with the most spend under management or the highest savings percentage was considered the ‘big dog’ in the room. Being known as a tough negotiator used to be a badge of honor. Today, however, with value as a priority and relationships as a key success factor, it is not unusual for those people (and their results for that matter) to be eyed with skepticism. What did you have to say to the supplier to get that rate? How hard did you have to push your stakeholders to get them to standardize their specifications? And what will be the cost of these actions down the road? Will anyone end up happy?

Whether we’ve articulated it or not, most people instinctively know that you can’t max out on savings and spend under management and also form collaborative relationships that generate sustainable returns and innovation in the long term.

In order to accommodate this shift in perspective, procurement has altered the nature of our relationships. We have worked to ensure that standardized processes do not serve as a barrier to opportunity. Although consistency is critical, and frameworks are put in place to help procurement scale our impact, it must always be in-scope to consider an alternative or out-of-the-box approach when the circumstances are right. 

If we are going to continue to advance the evolution already underway, the other thing procurement must ensure that is that we have a ‘proper fit’ relationship with our technology providers. When we evaluate suppliers for strategic partnerships, we compare the size of the fish to the depth of the pond. Do we want to be a big fish in a small pond (influential and dominant) or a small fish in a big pond (safe and overlooked)? The time has come for us to replace the relative size paradigm with one that more closely aligns with the objectives we are trying to achieve. Something other than size or volume should be allowed to set the expectations for procurement’s closest relationships – including our technology providers.


When you need assistance, time is of the essence. How fast can you expect a response and what level of familiarity do you expect the company to have with your situation? If the issue is not resolved immediately, will the same person remain with you throughout the process and ensure that you are satisfied in the end? Is the customer service you receive at this key time based on scale – anonymous and highly automated – or strategy – personalised and with a high level of ownership?


How would you describe the company culture where you work? Do you know what kind of a culture is in place at your technology provider? If they were to form a customer panel to collect and review requests for new functionality, what inputs would determine which companies were invited? Would the invitation process be based on scale – where only the largest companies are given voice – or strategy – where deep pockets are balanced with creativity and innovative applications of the technology?


Let’s say you don’t have a technical issue, but just want to get a better understanding of the technology roadmap and maybe ask a question or two. Would you have any idea who to call? Do you know the name of anyone who works at your technology provider or do you have to work your way in through a massive switchboard? Are regular interactions based on scale – where only contracted support terms enable you to get access to someone who knows something – or strategy – where the long-term benefits of being accessible and forming relationships with customers are understood.

Part of the most striking evidence that outcome-based procurement has led to the need for a redesign of what it means to be BIG comes from the choices traditionally big companies are making vis-à-vis their technology partners. While big fish used to be forced to swim in big ponds, large, innovative companies are recognizing the advantages of partnering with strategic, agile firms. As they move away from a scale-driven approach to procurement, they recognize that the only way to stay true to a strategic mission is by working with a technology provider that operates hands-on and with the same drive to achieve their objectives as procurement has.

How can Market Dojo help?

Market Dojo offer the best of both worlds, being leading procurement technology providers while also remaining immersed in the day to day application of their technology by working closely with their clients. For years, we’ve been told ‘it’s not personal, it’s business’. In today’s collaborative environment we might say ‘it’s personal because it is important business’. Let them help by defining and delivering on your idea of BIG.

Interested in reading more? Read our case studies:

Market Dojo helps procurement professionals negotiate better with our on-demand eSourcing tools. If you’d like to find out more, get in touch or register for free and play around with our software for yourself!

Tuesday, 14 February 2017

Cloud Services, or How We Learned To Stop Worrying and Love Instances

As Market Dojo expands, as all good startups hopefully do, they have begun to need some additional technical staff on hand to support, expand and maintain the eponymous software on which the business depends.

I am the first of these. James, at your service. Well, more at Market Dojo’s service, but since their goal (now, indeed, our goal) is to provide the best possible service to their clients there is a certain amount of inheritance. 
One of my first duties in this role has been to take at least partial ownership of the question “how and where do we host Market Dojo?”. Owning and managing our own ‘bare metal’ servers would be uneconomical both in terms of outlay and maintenance hours, so we have for the last few years outsourced that particular problem to $MediumHostingProvider. 

For a while now, however, the prevailing view within Market Dojo has been that our contract with them has been 'coming to an end’. This is in some ways a shame as they were an early partner in our journey and have provided us with excellent service over the last few years. Nevertheless, as our platform expands, with new features each release and a growing number of clients, the demands we place on our infrastructure itself grow accordingly. 

Currently the Dojo operates as a single shard on a single VPS (Virtual Private Server); this has been fine and workable for a long time, but our desire for resilience and scalability is pushing us to look further afield for solutions - there's only so much peace of mind a good backup system can produce.

It was suggested, and indeed attempted, that we could improve performance at peak times by increasing our various provisions. Since at Market Dojo we use Ruby on Rails as our app framework the expectation was that we would see increased responsiveness with an increase in memory in particular, as although the number of CPU cores available makes some difference Rails is less parallel than one might like.

On evaluation, this solution struck the team as decidedly suboptimal. In particular the difference in usage between times of high demand, such as the Monday morning rush of auctions from our larger clients getting the head start on the week, and times of low demand such as that experienced late on a Sunday afternoon grows linearly with the number of users; the latter case is negligibly close to zero usage by comparison. This would mean that simply increasing our VPS size was more apt to waste money and electricity than to provide a noticeable all-around benefit to both us and our clients.

Better solutions are out there. There are some very large cloud providers offering both IaaS (Infrastructure as a Service; Virtual Private Servers, for example, managed by the user) and PaaS (Platform as a Service; managed services which take care of the deployment, building and running of the background pieces behind an app, such as databases and web servers, as well as hosting) for various needs, most of which are intended to be scaleable. 

After some initial winnowing, we settled on a shortlist of three: IBM Bluemix/Cloud Foundry, AWS Elastic Beanstalk and Google App Engine for PaaS, and the same companies' offerings for IaaS - SoftLayer, EC2 and Compute Cloud respectively.

We had a number of requirements to consider in order to bring this down to a final choice.

    • First, security. We are currently GCloud accredited and registered as a secure service suitable for public sector work, and we wish to maintain that status. Thus, any offering worth considering had to meet high standards of security and reliability; not only because that offers us peace of mind internally, but perhaps more importantly because it enables us to maintain the surety and integrity we have promised to provide to our customers.
    • Second, and most obvious, was price. The ideal solution would not cost substantially more than our existing platform. We set a cap of about 15% increase; it's always worth being realistic about the fact that if one expects to gain something, there's often a price to be paid.
    • Third, equivalent offerings. With our existing capacity in hand, we wanted to be sure that we could have similar provision without having to customise too much; as it turned out this wasn't an issue, as all the providers offer similar instance shapes and sizes.
    • Fourth, user-friendliness. Time spent on ops is time not spent on developing features, fixing bugs or supporting clients. It's never a good idea to begrudge maintenance time, but for a platform to be appealing we had to be satisfied that it would not substantially increase the proportion of our day to day work devoted to keeping the metaphorical machinery oiled. A personal preference for a platform with a good and well tested CLI (command line interface) available was also on the checklist; the more that could be done without opening a browser tab and hunting down a phone to respond to the inevitable multi-factor authentication request the better.
    • Fifth, and uniquely to the PaaS offerings, we needed them to have either good buildpacks or a flexible deployment system, depending on how the platform was configured. Moving an app from self-hosted to such an environment involves dealing with the assumptions of that environment. That's all fine, good and expected, but if 'dealing with the assumptions' means rewriting large chunks of either the app or the configuration to fit that particular service then we would have to move on. Time, after all, is always in short supply. 

That last point was underpinned by a side concern of backward compatibility. Portions of the Dojo are in the process of being refactored, improved and reconstructed, others have already been seen to, but others still are yet to be addressed in this cycle. It's an undeniable fact that any piece of software older than one or two years will be at least partly outdated, unless it is particularly small or has a particularly deific development team behind it. For our purposes this ruled out any platform which enforced restrictions on versions of Ruby, Rails, or any of the various Gems upon which we rely.

The decisions became easier from there on. 

Full control
Someone else administers

Choice of web server
Provided managed web server

Billed by spec (predictable)
Billed by usage (auto-flexible)

Powerful CLI (Usually)
Easy GUI (Usually)

Typically cheaper than PaaS
Low technical knowledge barrier to administration

Can be expanded in real time to cope with changes in demand
Can expand themselves in real time to cope with changes in demand

Easy to automate setup via images or Puppet
Easy to automate setup via config file and push hooks
Have to administer manually
No control over software

Responsible for software and dependencies
Often hard to install additional dependencies

Requires technically competent administrator to make any changes
Narrow access routes

Typically more expensive than VPS

Can require official technical support to get anything major done

Tables make everything better. There wasn't a justifiable reason for a good chart or map in this particular investigation, but there were plenty of data to work with all the same. 

There were also a great many emails. An important thing to consider when you're contemplating a move of this kind, especially where it affects the nature of your underlying infrastructure, is how your larger clients might be disposed towards the changes. 

In this case, we consulted with two of our most active large clients, who were helpful in providing both recommendations and requests for the new infrastructure, as both companies have their own security teams. The ability to engage in this sort of collaboration with clients is a boon to all involved, relying heavily on the fact that commercial relationships in general, and security in particular, are inherently positive sum.

Elements of the feedback are confidential, but from our perspective one of the most important points raised was that there is an expectation of external assessment. If you happen to be planning a move of this kind, it would be advisable to budget from the beginning for engaging an independent assessor after the move has been made. We encountered this request before it became relevant, which is another advantage of having this consultation early in the process, so it didn’t constitute a temporal setback despite being effectively a change in scope.

In the ‘known knowns’ column, some of our clients have a strong preference for their data being stored in the EU, subject to the Data Protection Act. This rules out the major US data centres. Fortunately, all the services under consideration had datacentres in either the UK, Ireland or Belgium. We also had to consider encryption and colocation of data, such as would occur in a shared database or shared hosting. An encrypted-at-rest VPS is the very minimum expected, however, so those were not significant barriers.

Had we been looking at smaller hosting providers, or at self-hosting, we might also have had to consider redundancy of hardware in addition to the redundancy of data; one of the major advantages of using the large cloud providers is that they have all those concerns in hand; barring natural disasters, enemy action or Outside Context Problems they are highly unlikely to suffer full loss of data. 

Mitigation of at least the first risk, and in many cases the second, can be performed relatively simply by having backups in a datacentre in another environment. Our particular use case rules out the optimal configuration of having replicas on every continent and under multiple jurisdictions, which lowers the risk of coordinated attack or localised natural disaster (albeit raising the chance of encountering a subpoena); however, all three of our potential suppliers had multiple EU data centres.

All this in hand, we engaged in a deeper dive. 

For testing, we set a procedure:

    • Create an account on the service to be tested
    • Collect on the free trial, where possible
    • Spin up a new instance or equivalent with the same memory provision and number of cores as our current server
      • Points for speed, simplicity, price.
    • Add a database instance with the same specification as currently in use
      • Points for speed, simplicity, price.
    • Set up the environment with our usual software stack, where necessary
      • Points for ease of use, although as we’re likely to use Puppet or similar for future server setups and PaaS offerings do it all for you anyway this was not weighted heavily.
    • Deploy the app
      • Points for build speed where relevant; all the IaaS offerings were tested with Ubuntu 16.04 LTS so there was parity in manual setup.
    • Connect to DB instance if not automatically set up
      • Points for ease of use and secure internal networking
    • Check everything works
    • Evaluate ping, connection speed, server response time, and performance under load
      • We used Apache JMeter for this; it may or may not be the best tool on the market, but it’s excellent for a quick comparison.
      • Points for everything tested
    • Check run time and full billable amount, confirming against the initial estimates from the published prices
      • In theory, theory and practice are the same. In practice, they aren’t

The nice thing about establishing a procedure beforehand is that there isn’t much wiggle room for preference, not enough coffee, or whatever else might be distracting at a given moment. I’m always mindful of a study demonstrating that the simple act of having and using a checklist correctly reduces the incidence of mistakes and negative outcomes.

The result of all this data collection is still to be determined, but so far we’re quite pleased with the results. Overall, we expect to see both an annual cost saving and an increase in performance, at least initially; as we begin to use the potential of the cloud services to mirror, expand and scale the former of those gains may be sacrificed to the latter. That, however, is another article.

Market Dojo helps procurement professionals negotiate better with our on-demand eSourcing tools. If you’d like to find out more, get in touch or register for free and play around with our software for yourself!

Monday, 13 February 2017

[Case Study] Aggreko create 'Freight eMarketplace' using the Market Dojo tool

Chad Thibodeaux is the Central Logistics Manager for Aggreko North America-Americas. His duties involve the strategic sourcing for Aggreko’s transportation needs
When did you first consider using Market Dojo?

At Aggreko, we are the leading global provider of modular, mobile power, cooling, heating and air solutions. We supply to over 100 countries including to a number of major events such as the PGA tour and Formula 1 Race Days. This is in addition to our regular deliveries of rental solutions and power solutions to refineries, power plants and major construction sites.

We use multiple modes of transportation services to get our equipment moved throughout North America, but for the sake of this conversation, I will divide it into two major categories: local & long haul deliveries. The field service centres that are in close proximity to the delivery location are categorised as ‘local deliveries’. For the majority of these deliveries, we use regional service providers to deliver the equipment. For all of our long-haul deliveries which are further away from our service centres, we use approved service providers that can cover a much larger territory.

Initially, we recognised an opportunity change the way in which we procured our long-haul freight needs. For a number of years, it had been the responsibility of the local service centre teams for the arranging of vehicles and suppliers to long-haul destinations.

However, we felt that if we centralised our long-haul needs into a single central procurement team we might be able to generate high levels of savings and gain greater visibility on our spend. It was at this point that we considered using a tool that included an eAuction solution as it would give us the greatest potential for savings. We were recommended Market Dojo by a partner and have since been implementing it globally.

How have you been using Market Dojo?

Specifically, we’ve been using Market Dojo to create a ‘freight eMarketplace’, centralising all of our long-haul freight needs in North America and reducing costs through Reverse Auctions with suppliers. We have used our list of existing suppliers in addition to specifically chosen new suppliers to generate increased competition for each of the lots. Part of my role as the Central Logistics Manager is to liaise and manage suppliers and to oversee the outsourcing long-haul freight project.

What is your overall aim of using Market Dojo?

Our overall target is to capture and relay the data on a large scale, using those teachings to create further savings and thus getting better value for money, without compromising either the service from our supplier or the quality of service that we provide to our customers.

From the success that we have already had, it’s obvious that we will always be using an eAuction tool. Simply, the success has far exceeded any of the negatives and hopefully, we can continue to streamline and adopt the process on a greater scale.

What challenges did you face with the Freight eMarketplace?

Initially, we struggled with centralising all of the long-haul needs in North America to the new central team. Previously each of the field teams had organised with suppliers for deliveries in their local areas. However, we quickly found that in the past both our local teams and the suppliers had been using a different process to organise deliveries. Consequently, it took time for all of the suppliers to adapt to the new system.

Another issue was the resources needed to manage suppliers. Previously the workload had been spread across numerous teams in the continent. However, we found that with the workload we had to create an internal place within the central team to manage those vendors.

What didn’t you consider until you started the eMarketplace?

One aspect that we didn’t realise was the importance of sending a clear and consistent message to the freight suppliers regarding the eAuctions. In the freight transportation industry, eAuctions are not the norm. Therefore we had to educate many of our suppliers as to the process. At the start, we found a few issues with suppliers such as aggressively bidding but being unable to meet their obligations.

What have you heard back from suppliers?

To be honest, we have heard mixed feedback from suppliers. Some suppliers are unhappy with the process, mostly because those suppliers had previously been awarded a larger amount of business and only had to compete with a small number of other suppliers. Whereas we have heard very positive feedback from other suppliers regarding the process such as the immediate awarding of lots on completion of the eAuction and the increased level of competition, allowing for a greater number of suppliers to be considered.

Market Dojo helps procurement professionals negotiate better with our on-demand eSourcing tools. If you’d like to find out more, get in touch or register for free and play around with our software for yourself!

Monday, 6 February 2017

Analysing EU public spending data

Having recently researched thoroughly into OJEU (Official Journal of the European Community) and TED (Tenders Electronic Daily), I discovered the TED dataset for 2015 spend data.

This seemed like a great opportunity to try some different tools for data analysis and see what I could learn about EU spend data.


I usually use Excel to analyse data, but I also wanted to learn about R, an open source tool which is very popular with data analysts and the scientific community.

Quick facts

The 2015 dataset contains 542,376 rows.

The total value of the spend in the dataset was €763,502,408,895.25 (about €763.5bn). TED only collects data above OJEU thresholds and spend below the thresholds is at least three times larger!

The largest number of bids submitted for a contract was 940. This actually occurred on a framework for Child Daycare Services in Greece.

The largest award was €13.1bn for GP Out of Hours service for the York and surrounding area.

Value of contracts tendered


I knew from my research that the UK tendered the most contracts through TED, however, I was very surprised that it’s more than twice as much as any other country. I am really not sure how to account for this difference.

Value of contracts won

Once again, UK is well ahead, in fact, this graph looks very similar to the graph of contracts tendered. My research had led me to believe that one of the key purposes of OJEU rules was to eliminate trade barriers, but if the UK is tendering and winning the most, is this really happening? 

Country spending inside and outside national borders

Looking at whether money is spent with a supplier in-country or abroad, I discovered that most activity happens in-country. I didn’t have data for non-EU countries to compare, however, I was surprised at how little spend goes abroad. The most open country is France. I did also create a more detailed, country by country analysis for this.

Spending by Main Activity

The classic ‘other’ and ‘general’ categories are where the most money is spent. Putting this aside, I was surprised to learn that Urban Railway spending outstripped Education and Defence


Publicly available datasets contain some very interesting information. Data analysis tools such as Excel and R make this easier. These type of techniques can be applied by companies as well as countries.

Next steps

If this has piqued your interest, there is a fantastic website where you can investigate the data for yourself.  You can learn more about R on the website. You can also see how I generated the graphs here. Finally, I would love to know what you think about the results.

Market Dojo helps procurement professionals negotiate better with our on-demand eSourcing tools. If you’d like to find out more, get in touch or register for free and play around with our software for yourself!