B2B/B2C online strategy and enterprise eBusiness blog

Earlier this year, the Amerock Cabinet Hardware brand within our corporation was merged into our business unit already consisting of Levolor and Kirsch to create a combined Global Business Unit called “Decor”. The Decor Business Unit rolls up under the Home and Family Group of Newell Rubbermaid as outlined here.

What’s exposed when businesses merge

Previously, Amerock was grouped under a different Global Business Unit and run independently of operations at Levolor and Kirsch. The merging of these business units has presented an interesting challenge from a website strategy perspective. The challenges are not unique to us and the purpose of this post is to not outline the specific challenges we faced but rather to focus on the high-level areas that mergers and acquisitions will eventually uncover:

Business processes, software platforms, job responsibilities, and online strategy must adapt to the new environment.

Enterprise E-Business must be scalable

I am fortunate to manage a team of people who are eager to take on new challenges and responsibilities. What we quickly discovered as it related to our Online Platform was that it had all been built around a single business (blinds & shades). This meant some of the software was specific to business processes unique to Levolor and Kirsch but more specifically, our business processes were very tied to Levolor and Kirsch.

When Amerock was infused into the mix, we had to re-engineer several areas (listed below). I won’t go into how we modified these processes but at a high level, these were the core areas impacted:

Enterprise E-Business must function on repeatable processes

I cannot stress this enough particularly in the past few years in working in a Fortune 500 environment after coming from a small business of 20-25 employees. The enterprise is too massive for any one person to “know it all” so processes must be rigid, repeatable, with good people employed to manage through the processes and modify the processes when they identify deficiencies.

Tribal knowledge is acceptable in small business and is what enables small business to be agile. Tribal knowledge contaminates the enterprise, especially in the E-business arena. If an enterprise process cannot be repeated by more than one person without significant “hand holding,” then it is not a repeatable process. A merger or acquisition will quickly expose deficiencies in processes.

Scalable, repeatable processes does NOT equal inflexible online experience

Perhaps one area where IT folks get it wrong most often is deploying a scalable, repeatable process that limits creativity (particularly as it relates to an online experience). Scalable and repeatable processes must inherently have a mechanism for dealing with unique business requirements and the ongoing management of these “exceptions.” This is all the more reason why the E-Business/IT group needs a seat at the (business strategy) table. Without knowing the direction of the business, it is impossible to anticipate every possible scenario and build scalable, repeatable processes that will last.

The last 2 years in web startups and general usability improvements online have been fascinating. A product of this innovation period is a consumer/userbase of individuals who come to expect the same experience out of every web-based application they use online and at their day jobs. I love the passion!

There was a good post and subsequent discussion started at this blog asking “Why do enterprise applications suck?”

There is no disputing that most enterprise apps are terrible. Let’s examine why:

1. Enterprise applications span careers. Very rarely do you get an opportunity to start at ground zero in the enterprise with an application. Web startups have the luxury of starting with a blank sheet of paper. In the enterprise, you’re either integrating with legacy systems or building on existing processes that are engrained in the business. Furthermore, long-tenured “champions” are hard to come by as it relates to enterprise applications which brings me to my next point:
2. Enterprise applications are inherited. In my case, I’ve inherited a handful of applications from predecessors who inherited applications from their predecessors. Often times in the enterprise, applications that have been in production have years of usage behind them and are tightly woven into day-to-day business processes. Well, there must be documentation on how the software operates, right? Not quite.
3. Enterprise applications are wide in focus. Most web-based startups are narrow in their focus. In the enterprise, one solution rarely fits all needs and business processes, so you’re forced to do patchwork between disparate technologies. The startups that try to be “all things to all people” ultimately fail. Look at these lists of startups out of TechStars and you’ll find that they’re all laser-beam focused. Enterprise application providers are selling “one size fits all” solutions to corporate clients, so don’t plan on there being a community of “theme developers” for your enterprise app like there are for Wordpress blogs.
4. In the early days, the enterprise valued function over form. Looking back as little as 5 years ago, companies were still just discovering web technologies. When going from a manual, paper-based process to your first automated, electronic solution, everyone’s going to love it. Fast forward a few years and here we are, usability stewards with high expectations of web application usability. We’ve been spoiled with free services from the Google, Yahoo!, Facebook, and other online entities.

There’s a paradigm shift taking place with the expectations of applications

The evolving nature of web applications is no different than any other maturing industry. Automotive manufacturers experienced the same challenges. Early automobiles valued function: getting you from point A to point B. As that became the standard, automobiles had to differentiate on other features. Early enterprise applications valued function, however in the world of applications, advancements are not measured in decades like automobiles, they are measured in years or even months.

The enterprise will catch up.

Just like most consumers don’t rush out and buy the latest car or truck to take advantage of the latest and greatest innovations from the manufacturer, enterprises aren’t going to invest in software upgrades that don’t promise increased top-line sales or improved bottom line results.

That 1999 model year vehicle still serves its purpose — insurance is cheap, you have no car payments, and it still runs despite the occasional service it requires. The bells and whistles in new automobiles sure are attractive but they just aren’t enough to sway you to make the plunge for a new automobile. The same thinking is taking place in the enterprise with regards to the applications the organization invested in years ago.

As I’ve transitioned from the marketing department as a web marketing manager to the IT department as an application/development manager, to my now current role of senior IT manager, I’ve gradually moved up the food chain of strategy conversations with both the internal business, customers, and vendors. The constant theme in all of these discussions whenever IT is brought up? Resources (or lack thereof) and the roadblock IT is viewed as to growing the business.

Is every IT department eternally busy?

I don’t understand it. Well, actually, I do, but I’ll say “I don’t understand” just to make it sound like I’m in more disbelief than I really am. The underlying theme of every conversation I’ve had with a customer, vendor, or otherwise is that IT is busy and doesn’t have the resources. It seems as if any project requiring IT resources automatically gets held up in the “IT vortex” of priorities. IT departments are really not this busy.

The IT prioritization issue

Something is fundamentally wrong when IT resources are scheduled 9-12 months out. My gut feel is that what the business is being held responsible to do compared to what IT is being scheduled to do is at times, misaligned. This is not necessarily the fault of IT but rather the business leaders (in which IT should have a seat at the table).

From an operations and manufacturing perspective, we automatically know that it’s standard procedure to have a lengthy-but-calculated process for launching new products to the market. Yet, there’s perhaps somewhat less frustration with operations & manufacturing on these timelines compared to the frustration I commonly witness with IT scheduling. How can this be?

The business doesn’t understand IT

Business users simply don’t understand what they can’t see. Operations and manufacturing have the luxury of producing physical products and business users can see the progress of this development and can visually comprehend the effort that’s put into a product launch.

The challenge for IT leaders is to visualize the various IT processes, illustrate how they plug into the rest of the organization, and be viewed as an ally to projects and not a barrier to entry. It pains me to think how many projects are killed in the course of 12 months because IT resources are required.

Business users need a scorecard for IT projects

Business users need help — they can’t be faulted for not understanding IT, their lack of understanding is on the shoulders of IT leaders. Business users need a scorecard to appropriately rate their projects. There will be some things that internal IT cannot do in the amount of time required. But this doesn’t mean “kill the project!” It may mean outsourcing the project to another firm under the guidance of IT.

Unfortunately, many IT shops are one of the following:

• Run as if all IT-related ideas should be their own. This translates to extended timelines and lost time-to-market as IT puts the stops on a project because it wasn’t “their idea.”
• Operated under the watchful eye of a CFO. This translates to IT operating under the perception that “spending money = bad”.

What’s an IT leader to do?

1. Openly share your project pipeline (disguising projects that are sensitive, if necessary). The business as a whole needs to understand what projects are in the pipeline. If they don’t, they will approach you without any context to why your team is so busy — which is a problem.
2. Openly share the methodology for prioritizing projects with the business users who are submitting the requests. This will help them understand the process so that when they come to you with future projects, they will be armed the right data…and not with a preconceived notion that the project will “take a while” because “IT is always busy.” Knowing the “why” behind project prioritization goes a long way.
3. Accept the fact that you are not all-knowing. It’s OK for business users to come to IT with a new idea. You’re responsibility is leveraging technology to solve business problems and bringing their idea to life. Without you, it’s just an unrealized idea.
4. Spending money is not a bad thing. If you report to the CFO, the CFO is not against spending money. The CFO views business differently and is looking at the return on investment (ROI). If you cannot put in requests for money which outline the ROI, then be prepared to have many of your projects denied.
5. Don’t forget to position yourself as a “go to” person.

In this post about “Why Gen Y Is Going to Change the Web” from ReadWriteWeb, the following comment was made:

Work Tools Need to Mirror Web Tools: Gen Y will drive adoption of “Enterprise 2.0” products and services. Gen Y in the workplace will not just want, but expect their company to provide them with tools that mirror those they use in their personal lives. If socializing on Facebook helps them get a sale, then they’re not going to understand why they can’t use it at work. For more buckled down companies, if workers aren’t provided with the tools they want, they’re going to be savvy enough to go around I.T.’s back and get their own.

I couldn’t agree more — this thinking (expecting a company to provide tools to mirror tools in personal lives) is already prevalent today in the enterprise and it’s not even specific to Gen-Y’ers.

When users find their own way…IS can’t add value

I have an interesting perspective starting on the marketing side of the business and building up a website from scratch all without the help of IT/IS. The autonomy and flexibility we had to spend on innovation against a marketing budget was considerably different than having to jump through the hoops of IT layers in the enterprise.

Now that I have transitioned to a new role in the IS department, things are slightly different as I find myself combatting the very actions I was deploying when I was in the marketing department — employees working around IT’s back.

You aren’t issued a company cell phone from the model year 2001, so why should the web applications be any different?

I think the Enterprise 2.0 movement will be an important one. As consumers become more web-savvy, so will employees. Enterprise applications and development will need to quickly catch up to the speed of consumer applications and development.

After all, when we get a company-issued cell phones, we don’t expect to have a phone that’s representative of something from 2001. Why should web applications be any different? One may argue that you “don’t fix what’s broken.” While I love that principle, at the same time, a cell phone model from the year 2001 may not be broken, but there’s certainly a more efficient way of doing things today.

Put up roadblocks and employees will work around you

Frustrated employees will find their own ways of doing things and bypassing applications and processes in favor of a more pleasant and easy experience…or they just won’t use the technology at all. IT/IS departments will have a revolt on their hands in the coming years if they don’t begin to adopt consumer-oriented technology and applications.

This post about business processes as a competitive advantage hit home for me (it references a poor experience with an airline — which I’m sure we’re all familiar with). I am often jokingly ridiculed for how often I ask “why?” when evaluating internal business processes and the way data is organized in the enterprise. Quite often the answer is surprisingly, “I don’t know, that’s how it was done before I got here.”

In the link above, the same is true for the airline industry. It’s as if the entire industry was designed for an ideal world where there are no mechanical malfunctions, bad weather, or delays. Contingency planning and business process optimization go such a long way to improving operational efficiency and most importantly, customer satisfaction. Revisiting pre-existing processes is also a great way to find the low-hanging fruit of improvements.

When building any new business process or system, I find that the following question is helpful to ask over and over during the planning phase: Does this process add value for the end-user?

Such a simple question can go a long way to avoiding a situation like in the above post/link.

My first week has come and gone (officially) in my new role as eBusiness Manager. Not only is this a new role to me but we are also replacing two people on the team who had previously been in development roles for several years at the company. One is advancing to corporate and the other is leaving the organization. One replacement has been hired and his first week was very challenging, to say the least!

The Open Source Dilemma
I’m an enthusiastic supporter of open source applications and development. However, without proper documentation of home-grown applications, the cost savings up front of an open source deployment will eventually come back to haunt you down the road when those original developers leave. This is the exact position we are in. While it won’t be damaging to the organization, it will create a rather steep hill for the new developers to climb as they dive into the custom code (and lack of documentation).

When to buy or build?
This had me thinking during the first week in this new position — where is the line drawn between buying software and building software? I have to bring up a saying I use quite often: “Just because you can, doesn’t mean you should.” I think this is a perfect application for this phrase. I’ve discovered a lot of the home-grown applications were built as a cost-savings measure and “because we could.” That mentality has backed us into a corner today as we scramble to educate the new hires as quickly as possible before the original developers leave the organization.

Don’t view IS as a cost center
In talking with the original developers, it seems as if the mentality of the organization was such that IS was viewed as a cost center, not an innovation center. Therefore, an expenses incurred in IS were viewed as negatively impacting the bottom line. As a result, we ended up with a lot of home-grown applications utilizing different languages and database backends. This strategy works if you never plan to migrate to new technology and never plan to advance your developers.

Future-proof your IS strategy: standardize and document
Moving forward, we will begin to standardize on select platforms. We have a series of consumer websites, internal applications, intranet sites, and reporting spread across a myriad of technologies. Our downfall was this strategy (or lack thereof) which resulted in dedicated employees for managing each of the technologies/platforms. Since each platform was different, development was being handled in silos with very little strategy being shared between the silos. It also made us extremely dependent upon the individuals in charge of the silos.

Standardizing on a few select platforms and technologies will enable the proper cross-training among existing staff to be able to support applications in the event of individual vacation schedules, sick days, or departures from the organization. It makes sense from a technology strategy, business strategy, and also in keeping the sanity of your staff. It’s no fun for the weight of the world to be on the shoulders of a single individual.

Documentation seems to always take a back seat to projects in any business. In an enterprise like ours where we rely on reports and data feeds from external vendors, corporate IS, and other departments, documentation can save a lot of time and also prevent downtime. We have the fortune of being forced to start with a clean slate with new developers, so our first several weeks will simply involve documenting existing applications and systems.