Tag Archives: ERP

Reflections on 2007 – En Route to 2017 (Part 2)


I reflected in my last post on several significant milestones that mark 2007 on the journey to 2017 for IT organizations.  When students of IT organizational evolution look back on 2007 ten years from now, what might this year be remembered for?  I’ll continue this theme now.

reflections2.png

  •  Enterprise Systems unmasked as “no big deal” after all!

A veritable firestorm was ignited in the blogosphere when Robert Scoble dared to suggest that Enterprise Software (ES) is not sexy.  Firestorm aside, the fact is that ES has been among the top 3 initiatives consuming IT organizations (and their business partners) for much of the last 5 years.  Even if never “sexy,” ES did used to be big news – failures were common, successes were celebrated, and many CIO’s marched their companies on a relentless trek to the holy grail of ‘single global instance’ ERP – often to the virtual exclusion of all other IT progress.  It seems that during 2007, this march was no longer news.  For many organizations, while ES is still a ‘big deal,’ it is no longer in the top 3 initiatives.  One client of mine, proudly ‘late to the ES table’ rightly touts ‘last mover advantage’ – tons is known about how to successfully deploy globally common business processes, and they are shamelessly leveraging all this wisdom.

  • Maybe there’s a cheaper, faster way to Enterprise Systems after all!

One reason ES fell off the ‘big deal’ list is that during 2007 a potential alternative to the big ES software packages (viz SAP and Oracle) began moving into the mainstream – Software as a Service (SaaS).  The first serious foray into this new territory (at least for large global enterprises) was with Customer Relationship Management (CRM) and Salesforce.com’s success.  Although only covering a limited slice of the ES landscape, Salesforce.com proved an important point – what had been previously unthinkable was now a valid alternative, raising questions about the multi-hundred million dollar, three year implementations common to ES installation and deployment.

  • Former on-line bookseller becomes seller of web services!

I don’t recall seeing this headline this year, but it could have happened.  Well, it did happen (the factoid, that is, not the headline!) – Amazon.com entered the web services business, leveraging its internal technology platform.  While this is by no means the first time a “non technology” company has launched a technology business, the fact that such a huge and successful on-line retailer is opening up its crown jewels speaks millions about the SOA and SaaS breakthroughs highlighted earlier in these Reflections on 2007.  It also marks 2007 as the “Year of the IT Platform.”  More on this later…

About these ads

Language and Business-IT Maturity


Language has some interesting relationships to Business-IT Maturity.  As a management consultant, one of the things I have to do is quickly calibrate a client’s situation – sometimes, in just minutes (e.g., with a new, or potential client).  I’ve had some version of the Business-IT Maturity model in the back of my head for many years – it’s become a lens I use to calibrate where a given company is in terms of business maturity with IT, the maturity of the IT organization, how progressive the appetite is for business demand, how progressive the ambition is for IT supply, and so on.

Often, clues about these characteristics are found in the language people use to talk about thier situation.  Many years ago, there was a quiet move afoot to stop calling business clients “end users.”  As one wag said to me, “The term ‘user’ has a narcotic connotation – they become dependent upon IT, and we act as if we are drug dealers, fostering that dependency, then abusing the relationship!”

More recently, I find clients struggling to distinguish between internal business customers, and the external “consumer.”  These terms never quite work right – there is the age old debate between client and customer.  Generally, client is used where services are being delivered, and customerwhere products are the object of delivery.  Unfortunately, IT organizations, in some senses, deliver both services and products, so the distinction is somewhat limited.  I have clients who have banned the term clientas connoting a service provider model, and therefore implying “order taking” behavior.  I’m not sure I agree with this connotation, but if your CIO has a passion about terms she hates, or terms she’s trying to inject, logic does not do much good.

Anyway, with the Business-IT Maturity model in mind, I listen for these audible clues in the client’s use of language.  If I hear a lot of “us” (IT) and “them” (the business), chances are they are Level 1 or low Level 2.  If I hear the customers/clients referred to as “users”, chances are they are low Level 1.

If the conversations seem to be mostly about costs, they are Level 1 or low-to-mid Level 2.  If the conversations are mostly about value, they are high Level 2 or Level 3.  If I hear lots of discussion about Project Management, but none about Program of Portfolio Management, the client is likely low Level 2.  If I hear the terms Project, Program and Portflio being used in ways that consistently differentiate between them, and imply the relationships among them, they are probably high Level 2 or Level 3.

If the dialog is mostly about ERP, and major transactional systems, they are probably Level 2.  If the discussion is more about innovation, growth and IT as a source of new revenues, they are high Level 2 or Level 3.  Increasingly, if the conversation has a heavy dose of “collaboration,”  “social networking,” “Next Generation Enterprise,” or “Web 2.0,” at least I know there are some ambitions for Level 3 – though possible a long row to hoe to get there!

Of course, these points about listening to the language is simplistic – I have 30+ years of experience that helps me calibrate Business-IT maturity.  Sometimes, the earliest impressions prove to be wrong – but rarely.  Usually, my early instincts are correct – the things I learn subsequently are more “fine tuning.”

By the way, there are also visual clues, if you are physically with the client – books on people’s shelves, scratchings on whiteboards.  Increasingly, I’m finding office layout to be a clue (amount and quality of team rooms, coffee break areas for social networking, etc.) is a clue to maturity.

So, what does the language and terminology in your company tell you about Business-IT maturity?  How would you expect the language to change as a reflection of increasing maturity?

More on the Sticking Point


As I get ready for a week’s vacation in Aruba (lots of Scuba diving and time with my family!) I want to explore a couple of more aspects of the “sticking point” that I see IT shops bogging down in as they mature from Level 1 business-IT maturity towards Level 3.  The sticking point is at the inflection point in the middle of Level 2.

I talked in the last post of the shift in Enterprise Architecture from an IT-out, bottom up perspective, to a business-in, top down perspective.  This is the type of shift that does not work by just “working harder at EA” or by throwing more resources at it – it takes a significant shift in approach.

Getting out of Level 1 into Level 2 is mostly about rigor and process discipline.  Process Management, CMMI and ITIL are the types of formal disciplines that bring order to the chaos of Level 1.  These all make sense – in fact, are essential (these, or similar process methods) especially given that much of the work of maturing from Level 1 is about cleaning up the IT infrastructure (“getting the trains to run on time” or “keeping the lights on” as the metaphors go) and implementing enterprise solutions (ERP, for example).

The trick in getting through Level 2 and to Level 3 is not so much to throw out the disciplines that got you out of Level 1, but to apply it in a much more selective and gentle handed way.  The types of business problems and solutions that are common in the higher reaches of Level 2 and dominate Level 3 are more about business experimentation, and less about rigorous formal specifications and requirements management.  While project management continues to be a foundation skill, program management and IT portfolio management become key in Level 2 and the Scientific method becomes an important alternative to requirements management.