The Need For Speed

In the world of SaaS enterprise applications, starting a successful implementation project is all about the need for speed.  Customers have subscribed and are itching to work with the software.  Implementation partners want to quickly take that next step the change management process, which requires the customer getting familiar with the software.  

So setting your fledgling project on the road to success depends on getting an instance up quickly (among other things).  Call it "Conference Room Pilot 1" or a "sandbox" or "the staging instance" or whatever else you like, it's important to get an instance up as quickly as possible.  In all honesty, it does not need to be populated with customer data, customer configurations, nor customer business processes.  In fact, it is usually better to put up a very plain "vanilla" instance and encourage the customer to try out the business processes baked into the software in order to limit or eliminate customizations later in the project.

An important early step in the sprint from subscription to first valuable use...get an instance up as quickly as possible.   Embrace the need for speed.

You Get What You Test For

You get what you test for. - author unknown

When you move to the cloud, you leave much of the burden of on-premise applications behind.  But one thing you won't leave behind is testing.  It's a basic premise of configuration management:  when things change, you test.

In terms of testing, nothing changes when you move to the cloud.  Every version upgrade, every patch, every whatever-they-call-the-change-this-month, you test.  Functional unit test, integration test, system test, performance test, and so on...it's all still with us.

It's all still with us because, in most cases, patches and updates are built for a large number of customers.  And there may be variations across that set of customers.  Some of those variations will cause changes in results from one customer to another.

At the end of the day, each customer has the ultimate responsibility of making sure their cloud system works for their unique situation.  The same system with the same configuration will not work for all customers, any more than the Chevy Spark my wife drives for urban commuting will work for someone whose primary need is an off-roading vehicle.  So if Chevy were to make a suspension system change to all vehicles across the board, it may act differently for the off-roader than it does for my wife.  So...we test.

It's your system, regardless of whether it's in the cloud or not.  And you get what you test for.

I Can't Stand It

I can't stand it
You're fooling around, I can't stand it
You're running around, I can't stand it
You're fooling around with my heart
                     - From Eric Clapton's "I Can't Stand It"

I've taken leave of writing about Oracle products and services.  Since joining Oracle and "taking the King's shilling", I felt that I could no longer be an impartial voice.  But I just can't stand it anymore.

My energies and my passion for the world of tech is, to a huge degree, wrapped up in Oracle.  I see things happening.  I read the opinions of others.  I hear things.  And I feel the urge to jump into the mix.  Refraining from doing so has somewhat sapped that energy and passion.  So I'm jumping in again, here, on LinkedIn Pulse and on my Twitter feed.

As I do this, you need to know a few things:

1. I can't talk about products or services pre-release
2. I can't share information about release dates
3. There is a limit to my impartiality.  After all, Oracle puts the roof over my head and the food on my table.
4. All the opinions expressed by me anywhere are entirely my own and should not be construed in any way as opinions, comments or commitments on behalf of Oracle Corporation.

Yeah, I think that's about it.  I can't stand it no more.  Game on.

Self-Service vs No Service

Self-service is a huge trend in enterprise software.  The basic idea is that, rather than expending the service provider's resources on simple matters, simply enable your customers to handle the matter on their own.

The idea did not start in enterprise software.  Think of self-service gasoline stations, buffet-style dining, loading items into your shopping cart at Trader Joe's; all examples of self-service.

Done well, self-service raises customer satisfaction while decreasing provider costs.  I'm a long-term fan of Expensify - a product that optimizes the experience of self-service expense reports.  They are an example of self-service done well.  Done poorly, customer satisfaction plummets to the point that customer loyalty is vaporized in an explosion of frustration.  Think of the virtual receptionist used with most customer support telephone lines...one wonders whether the idea is for the customer to help themselves or simply keep them in a a vortex of navigation options until they simple give up and hang up.  That's done poorly.

There is simply no better or quickly way to destroy customer loyalty to a product or service than to route communications with that customer through a service hub with an automated attendant. It's a strong message to customers that a service or product  provider does not care about you, your issue, or your feelings regarding the experience of using the product or service. "Thanks for buying...hope all goes well, we're outta here"!  No service.  I'm always a little taken aback when I see it.  And I see it more frequently these days.

Some self-service is good. For example, I prefer to write my own trouble tickets - I can be much more precise about my issue when writing it up myself as opposed to explaining things to an analyst.  But the follow-up should be someone reaching out to work my issue.  When Step 2 consists of automated self-help suggestions, I know I'm in for a frustrating experience because we've crossed the line into the realm of no service.  (it's like taking my iPhone to the Genius Bar and hearing the phrase "As it turns out..." - it's a guaranteed sign that frustration will follow).

Customer service still matters.  Want to keep your customers...and even make those customers advocates for your product or service?  Take care of them after they buy.  But don't make that transition into no service...unless you're ready to shrink your customer base.

I Love It When A Plan Comes Together

I love it when a plan comes together.
                    - John "Hannibal" Smith

So I had a really cool conversation with a long-time friend over the weekend.  The friend is CFO at a Fortune 2000 company…I won’t call him out here for privacy’s sake, but you would recognize the company name.

Anyway, friend was telling me their story in going to SaaS.  It’s worked out very, very well based on some decisions made early in the process.  We burnt the midnight oil together working through some of those decisions, so it’s always gratifying to hear that they worked out.  I thought I’d share a few here in the hopes it might help somebody reading this…

1. They knew what they wanted going in…much more specifically than simply “transforming the business”.  The desired end states were: a) an improvement in the speed of responding to market-driven changes, and b) a substantial reduction in IT operating expenses.  That’s it.
2. Their approach throughout the project was a strict application of Occam’s Razor:  the solution requiring the fewest assumptions was the right one.  They were passionate about keeping things simple.
3. Another thing this company was very passionate about:  letting go.  Very little data was converted to the new SaaS system.  They started with opening financial balances and historical queryable flat files from their legacy system.  They took a similar approach with their HR records.  Saved huge amounts of money and time in switching to SaaS.
4. More on the letting go thing:  they let go of all their old business processes, opting to use those baked into their SaaS applications suite.  At their first Conference Room Pilot, they came out with an 80 percent fit.  With careful planning and tailoring, they increased that fit to 90 percent by CRP 2.  The last ten percent?  Some of it they decided they didn’t need and some of it wound up on a small, on-prem server integrated with their SaaS apps…mostly at the reporting/BI level.

So the end results?  

First, I should mention that it took this particular company four months to implement and cut over; it could have been quicker, but they invested about one-third of the project effort in “kicking the tires” before going live.  Brilliant...and definitely not my idea.  The testing effort turn out to be a huge help with user adoption within the company.  

Second, they have reduced their IT operating costs.  According to the CFO, IT operating expenses dropped by over 60 percent, mostly due to eliminating the need to maintain their in-house applications suite.  Although my friend also cynically notes that most of the savings from software licensing and support fees was consumed by SaaS subscription fees: “all the SaaS vendors had already worked the numbers on that part of the deal.  Even so, the savings realized through reductions in infrastructure and in-house support were a little more than we expected.”  

Third, are they responding to market changes more quickly?  “The jury is still out.  We just don’t have enough data over a significant period of time to know for sure.  But we have made a few changes based on reactions from our customers and we’re responding in days and weeks rather than months.  We hope that continues."

Are there speed bumps in this story?  Of course.  There's always a little manure involved with the prettiest flowers.  But overall, it's a pretty gratifying story.  By understanding their desired end states before starting the project, by treating simplicity as a discipline, and by letting go of the past to embrace new things, they have some pretty solid early returns.

So, real life.  Somebody got it right.  I love it when a plan comes together.  Don't you?

An Old Trick From An Old Dog

Old dogs look you in the eye, they hold your heart, they never lie,
They bark at planes up in the sky and wish that they were fliers.
Old dogs dream about the past when they frolicked fields of golden grass,
And chased the icy winter's blast, to lie by home fires burning.

Old dogs wander off alone but old dogs know the way back home,
The slightest scent, the buried bone, the hunter home returning.

                                                   - From "Old Dogs" by Bill Staines

I was recently asked how I evaluate different enterprise applications systems.  In all honesty, it's pretty simple:  I use a conceptual chart.  Yeah, really, a single chart.  This is it:

So I look at three different layers of components:  business value, development and deployment.  And I consider the components listed above in each of those three layers.  

I may dig a little deeper in some areas.  And I may even get into some classic system engineering analysis, with figures of merit and all that, but this is the upshot of it.  No sales hooey, no trendy buzz terminology, no nothing.  This is it.  I also use it for solution evaluation:  it's a great little framework for peeling back the layers of the onion and exposing solution risks.

Been using this framework for around seven or eight years now, so I guess that it qualifies as an old trick from an old dog.  But it still works.

An Old Trick From An Old Dog

Old dogs look you in the eye, they hold your heart, they never lie,
They bark at planes up in the sky and wish that they were fliers.
Old dogs dream about the past when they frolicked fields of golden grass,
And chased the icy winter's blast, to lie by home fires burning.

Old dogs wander off alone but old dogs know the way back home,
The slightest scent, the buried bone, the hunter home returning.

                                                   - From "Old Dogs" by Bill Staines

I was recently asked how I evaluate different enterprise applications systems.  In all honesty, it's pretty simple:  I use a conceptual chart.  Yeah, really, a single chart.  This is it:

So I look at three different layers of components:  business value, development and deployment.  And I consider the components listed above in each of those three layers.  

I may dig a little deeper in some areas.  And I may even get into some classic system engineering analysis, with figures of merit and all that, but this is the upshot of it.  No sales hooey, no trendy buzz terminology, no nothing.  This is it.  I also use it for solution evaluation:  it's a great little framework for peeling back the layers of the onion and exposing solution risks.

Been using this framework for around seven or eight years now, so I guess that it qualifies as an old trick from an old dog.  But it still works.