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.

You Can't Do This Backwards

Having returned from a stay-cation invigorated with new thoughts...

There was a time in the world of enterprise software when one could snap up some cool, interesting technology and figure out a way to leverage the new, shiny stuff in a way that benefited the enterprise.  Those days are long gone, if for no other reason than the enterprise software vendors are cranking out new applications, tools and technology far too quickly for a technology-centric user to keep up.  My own employer, Oracle, releases Cloud products at a rate of several per month.  Think about that for a minute:  we're not talking patches or releases, but entirely new products.  That's mind boggling.

In the age of fast and furious enterprise software development, you have to think the business results out ahead to time - what are your desired results or end states?  Then acquire the tech you need to make those desires reality (keeping in mind that you can often use what you already have).  

You can't do this backwards anymore, because it's so easy to get lost in a sea awash in products.

SaaS - Some Food For Thought

Had an interesting conversation with a new SaaS customer this week.  Big enterprise customer, along with an implementation partner, is making the move from on-premise systems for all of their Sales applications and HCM applications to SaaS applications. And they're leaving their financial systems on-premise, hoping to integrate between the SaaS apps and the on-premise apps.  To make the mix spicier,  they've picked different platforms for the Sales apps and HCM apps...same vendor, but obviously different platforms for HCM and Financials.  The approach they're taking is "lift and shift" - we want all our existing processes and reporting to survive the transition.  And they want to go live with Sales and HCM simultaneously...aka "big bang."  Fortunately, it's all in the planning stages...no purchases of SaaS yet.  I got called in to provide some advice.

I'm sure you can imagine my muffled screaming while drowning my frustration in Dr. Pepper over the approach this particular customer has planned out.  No need to hash that out here.  But my advice actually turned into a set of questions...good questions actually, which is why I thought I'd share them here.  Here we go:

1.  Can you describe the desired outcomes you hope to achieve by moving from on-premise to SaaS for Sales and HCM?
2.  What synergies do you hope to achieve by transitioning Sales and HCM simultaneously versus taking a staging approach?
3.  Do you have an inventory of your current assets?  Especially the state of your data?  How much historical data to you plan to convert to the new system?  How about a list of current data model customizations and the reasons behind each customization?
4.  Have you considered and examined the business processes baked into the SaaS apps you're considering?  Could the baked in business processes work for you?  And, if not, why not?  Could the gaps be addressed within the functionality of the SaaS apps?
5.  Have you measured how often each of your current reports is used?
6.  What are the metrics that will help you know that you've achieved or fallen short of each of your desired outcomes?
7.  What do your stakeholders - especially your administrative specialists and first-line supervisors - think of this project?
8.  Has anyone attended any training for any of the SaaS apps you're planning to implement?  If so, what feedback do they have from the training?
9.  Who are the C-Level sponsors for this project?  What is the plan for keeping those sponsors engaged?
10.  On a scale of 1 to 10, how willingly and quickly is your enterprise willing to change?  Just gut feel, right now...what's the number?

I had a few more questions that are unique to this situation, but I started with these.  Any guesses on how the conversation went?  Bottom line is the customer is taking a step back to reconsider their approach and the partner is grateful for that (the partner execs had that look on their face that you see when they realized that loss hemorrhaging on a fixed-price contract is about to begin).

Now nothing special came from me here.  Just a few simple questions, most of which we've been kicking around for at least a decade now.  So save your project early...feed your stakeholders some food for thought.

If you've got more good food for thought questions relating to SaaS implementation, feel free to share in the comments.