ARMOR, n. The kind of clothing worn by a man whose tailor is a blacksmith… — Ambrose Bierce
10 days ago I began a Software-as-a-Service (SaaS) deployment project for a billion dollar division in a multibillion-dollar telecommunications enterprise. The project calls for taking a wholly outsourced business process that I set up as a prototype for the global organization there nearly 2 years ago and redeploying it as a more refined and optimized workflow.
It will consist of more than new twists and turns, bells and whistles. It will rest upon a rock-solid data quality control backbone that can ensure system adoption, because the end-user base will have limited reason to complain about the validity of the data flowing through the SaaS system. The migration project will take 3 months to complete.
In the more than 10 years that I’ve produced these types of systems for other multi-billion dollar companies, my team has built modest data warehouses, where to deposit rather granular data about customer accounts, contacts and their transactions with the business, collected through various touchpoint systems. What kind of touch points?
We’ve used product entitlements data to learn what kind of support the customer had a right to expect from the company; tech support trouble tickets to evaluate trouble spots in customer satisfaction; purchase orders to estimate the customer lifetime value; demographics to segment the customer into niche markets, and response data to determine customer interests and demand.
We “machine washed” a lot of this warehouse data using sophisticated software and to build data marts. In other words, we took all the granular Lego pieces of data inside the warehouse and aggregated them into bigger, connected pieces that analysts could break down using dashboards or business intelligence tools.
There were times when we had to “dry clean” some of these data to make it useful to the business, and we shipped it off to specialists for that purpose. But most of it got taken care of in bulk through automated processes rather than by hand.
These kinds of projects are highly complex. When starting in my career it took me practically 4 years to complete one of them end-to-end. Next time it took 2 years. The most recent project took 1 year. This one that I’m working on now I’m aiming to complete in 6 months 3 months working like a mechanic under the hood, 3 months working as a driver’s ed teacher showing people how to use the machine.
I anticipate that in my next project I may be able to set up an entire service of this kind within 1 fiscal quarter.
How?
SaaS technology has made possible within a decade to take a 4-year project and reduce it to less than 1. Whereas I used to have to license specialized software, get it installed in-house, hire consultants while my direct reports got trained on it before I could get it going, now a lot of that ramp-up effort and maintenance can be outsourced under a SaaS arrangement.
Even integration of multiple SaaS solutions can be done today by another SaaS in the clouds, so that your entire business operation is outsourced to multiple service providers.
But let me tell you the dirty little secret no SaaS provider will confess to you without some arm twisting about these new super-duper, simpler than sliced bread outsourcing models of operation:
If you can’t integrate the SaaS technology in such a way as to keep your own data clean and safe while entering the system and on a continuous basis, then you’re on your own, buddy! Thats the SaaS way. Its what Im having to face today.
I Lease You Technology. YOU Mitigate The Risk Of Using It.
Let’s take a detour for a moment and talk about Marketing and IT.
Marketers hire marketers, which is why, when in need of working with databases and business intelligence tools, they hire database marketing managers and marketing analysts. IT hires technicians, which is why, when in need of working with databases and business intelligence tools, they hire database developers and data analysts.
But who hires the one who does the following?
- Understands marketing strategy
- Can convert it to workflow logic
- Can identify decision points along that marketing workflow
- Can recommend rules to implement at each decision point to ensure marketing work aligns to strategy
- Can translate the envisioned strategy into an operations process requirements inventory
- Can build the business case for fulfillment of these marketing operation requirements
- Can conduct workload breakdown, critical path identification, scheduling and resource loading to manage fulfillment of marketing requirements via a SaaS deployment project
- Can test, refine and roll out the new process solution technologically
- Can measure new process acceptance and success factors for on-going process and technology improvement
Well, it’s neither the database marketer nor the marketing database developer who can do this. It’s the Marketing IT process strategist, a blend of marketing strategist and system integrator.
The Marketing IT process strategist skill set is hard to find but crucial for marketing automation project success, because whether marketing or IT brings it on board matters little, so long as it is understood that this function requires someone to be at work right at the interface between the business and the technology, facilitating and translating between the 2 groups like both an interpreter at the UN and an adjudicator at an arbitration court.
What Does This Have To Do With SaaS Integration?
One of the main reasons why marketers run to SaaS is because they wish to escape relying on their own IT organizations to deliver the technology that might make the marketing operations strategy possible to execute. But there are realities that confronted SaaS subscribers and which cannot be denied:
- A SaaS subscriber loses application performance control because the systems back-end is not on-premises but in the Internet cloud somewhere.
- Feature development cycles for the SaaS provider don’t match the client’s demands for deliverables. If the shoe didnt fit, you will have to get rid of a few toes.
- Subscribers must handle the added cost of system integration and data migration to keep the SaaS application from remaining isolated as a data island. You thought it was plug and play? What if there is no plug in your SaaS to fit your in-house jack?
- Subscribers must mitigate data security risks when engaging a SaaS in a shared-application service model. Are you Sorbanes-Oxley (SOX) compliant? Will your SaaS keep you that way?
- Within 24 months of subscription a SaaS client may end up paying for the full cost of owning an equivalent on-premises technical solution, yet only ends up possessing nothing but a subscription service level agreement (SLA) starting on month 25.
Without a plan to mitigate all these risks, it is likely that the IT organization will resist the use of cloud computing to run a mission-critical Marketing operations infrastructure outside the companys firewall over the long-run. Or let’s say IT has its hands full and won’t object. They also won’t come to your rescue if you screw up.
In the meantime, the marketers are collecting your mission-critical business data in these external systems and leaving a crucial corporate asset exposed to unmitigated risk.
It is unlikely that an IT organization will welcome having to bring data back home from a SaaS environment, when the data left home like a proud prodigal son vowing never to return. If something goes wrong with the SaaS, how exactly is the client going to recover?
If you have an on-premises software suite and you pressure the provider for restitution for some bug, you get results. Its in the contract. But if the network, which the SaaS does not own but on which the SaaS depends to deliver services to you, goes down and you cant do business because of it, then you would have been better off creating a more localized solution with your IT colleagues. Which is the better way? A Marketing IT Process Strategist should be able to help you find out for your particular case.
Same Size Fits All. But Are You Part Of The All-Team?
The architecture of a SaaS application is designed to disallow customization. A SaaS is meant to support multiple customers using the same software code. No one customer therefore can configure a distinct module of that code whatever way needed, because it would impact the base code shared by other customers of the SaaS provider. Its that simple.
It is easy for SaaS customers to underestimate the effort required to implement these service solutions, particularly in large enterprises, despite the emphasis that SaaS suppliers place on ease of implementation. Dont fall for it, unless youre a start-up and have no business process to speak of or a small business willing to use a SaaS as a stepping-stone into a more scalable situation as you grow.
But for large, global marketing enterprises with dependencies to internal systems and a relationship to keep with their IT organizations, the key is caution with the guidance of a Marketing IT Process Strategist. Don’t put yourself into a SaaS straight jacket.
Return to Marketing Automation from Avoiding The SaaS Integration Straight Jacket
Return to How A Marketing Agency Influences A Marketing Database Project Page