4 steps to a successful Technology Evaluation

When you get an Enterprise Architecture established, it's critical to institute a Technology Evaluation process, to methodically analyze and introduce new technologies as needed. As an organization, you'll want to ensure new software purchases are adequately governed, to continue striving towards the EA nirvana of reduced IT and business process complexity.

As I see it, there are four key steps to running a successful technology evaluation:

1.) Gather Requirements
This is the most critical step of the evaluation. The requirements must be detailed enough to quantitatively score the vendors' abilities to meet them, and be from each stakeholder group in the business and IT. This must happen first, so that you get a good idea of everyone's requirements before vendor demos happen. If not, everyone's requirements later will look oddly enough like the shiniest vendor's brochure.

Additionally, don't forget to weight your requirements. Some requirements are simply more important than others, so you'll want to adequately weight them with percentages to reflect these priorities when the vendor ratings are applied later.

2.) High Level Evaluation
Next is to put together the long list of possible software vendors that could meet your requirements. You may already know of some from your past experiences, but other good sources of vendor information are Forrester, Gartner, and any procurement partners your company may work with.

Working with this long list, perform a high level software vendor analysis. If you don't have much hands-on experience with the software options, schedule some vendor demos, or send each vendor a Request for Information (RFI). By the end of this phase, trim down your vendor list to 4 - 5 vendors so you don't get stuck in analysis paralysis in step 3.

3.) Detailed Evaluation
This is where most of your time will be spent during a technology evaluation. The two most important components of the detailed evaluation are:

• Sending a Request for Proposal (RFP) to each vendor that contains all of your detailed requirements, with a quantitative list of possible responses for as many requirements as possible, so you keep your detailed reading of free-form text boxes to a minimum. An example of a quantitative response list would be: 5 (Meets requirement out of the box), 4 (Meets requirement with minimal configuration), 3 (Meets requirement with significant configuration), 2 (Meets requirement with customization), 1 (Meets requirement with third-party tool integration), 0 (Does not meet requirement).
• Conducting detailed vendor demos. Be sure to give the vendors plenty of guidance in advance on specifically what you want to see during the demo, and capture your team's feedback on the vendor immediately after each demo to make sure nothing is forgotten.

Sometimes you will want to speak with customer references as well, especially if you want to validate some implementation questions (such as how well the software really does integrate with another tool).

4.) Vendor Selection and Communication
You've done it! All the information you need to make a rational, informed technology selection has been gathered, and in a quantitative fashion. Now combine the detailed RFP responses with the qualitative vendor demo feedback, and lock your team in a room for an hour or two (or three) and come out with a decision.

Don't forget to communicate the technology decision to the rest of the organization. Since the software was chosen in partnership with Enterprise Architecture, it should be reusable by other groups in the company with similar requirements, so make sure they know about it.

5 steps to governing a global process template in SAP

We've had a fantastic Accenture resource on site for the past few days, helping us develop an SAP Solution Manager deployment roadmap for our organization. For those of you who have heard of Solution Manager (or Solman, as it's lovingly nicknamed) you know it's a huge collection of many different capabilities, and can be overwhelming to those organizations first dipping their toes in the tool. One of our key learnings was the list of 5 (easy?) steps to creating and governing a global process template.

1. Create a Global Template project in Solution Manager and populate it with your favorite business process framework. (SAP provides one, if your company doesn't already have one established.)
2. For us, we use ARIS as our business process modeling tool. So once we have our business process framework in Solman, we'll export the template to ARIS to align our global business processes and detail with the business.
   
3. Once the business processes are complete and validated, they are exported back out of ARIS into Solution Manager. Ta da! Global template! It's now ready to populate with globally-relevant documentation, like configuration rationale.
4. Once the global process template is complete, it's realized through Implementation projects. These projects are set up to put the necessary SAP technologies in place. When an Implementation project is created, it automatically utilizes the processes within the Global Template.
   
5. After an Implementation project is complete, a Maintenance project is created for break / fix, enhancement, and other support purposes.

Of course, the hardest part is aligning on your company's global business processes in steps 1 and 2, which is the whole point of creating and governing a global template in the first place.

Warning: Enterprise Architecture Bias

Just to give all readers fair warning: When it comes to IT management topics, at the moment I'm Enterprise Architecture biased. I'm watching a fledgling, 3-year-old EA organization at a large consumer goods company continue to tussle and transform, and I can't help but wonder how many other fledgling EA organizations are out there. Are you out there?

Consultants have come and gone, managers have come and gone, and the organization continues to undergo change, challenged with little stabilization in its focus and direction. But the group has learned much, and it's these learnings that will be shared.

Enterprise Architecture as a theory and a practice has been around for at least 20 years, but it's never been as pursued and widespread in corporations as it is now. It continues to grow, but not without its challenges. On average, consumer goods and manufacturing companies give an EA organization six months to show value before it's disbanded. (Source: Corporate Executive Board.)

Six months. That's a helluva short time.

So it's with this somewhat sick fascination in the common question "Why EA?" that I begin this blog. Are there more of you out there?