What Is a Solution Vision?
With the understanding you have gained in terms of what an SAP project looks like, we are ready to begin refining and later communicating a vision of the future-state of your SAP solution, a solution vision. Think of this as the “eyes closed” phase of the project, where wishful thinking is tempered by constraints like budget and headcount realities to sketch a design that meets both business and financial requirements, as you see in Figure 3.1.
Figure 3.1. The solution vision melds company needs and constraints into an achievable business vision facilitated by technology.
In the narrow role I have personally played helping my customers to craft such a vision, I give the following advice to executive and senior IT decision makers, and other members of the SAP project steering committee:
Generally, focus on your core business and how an enterprise solution will better enable that core business to be successful.
Identify the shortcomings of the systems and processes in place today. For example, is it difficult, expensive, or cumbersome to customize the system? Are employees forced to duplicate entries in multiple systems, or access different systems for different customers? Is the system subject to downtime because of hardware and other solution stack issues?
Clearly define the value that you believe those systems should provide to the business. That is, should the system be available 24×7? Should it be accessible over the Internet or your company intranet? Should it tie together different functional and business areas, or enable real-time decision making?
With the data collected in response to the questions in the previous two bullet points and with your real business requirements nailed down in Chapter 2, step outside of the “box” and consider alternatives and “nice-to-haves.” Enlist the assistance of your own long-time end users and the insight of your current IT staff to begin assembling a new solution vision that describes what the system should be capable of.
Solicit the advice of mySAP.com experts to assist you in identifying real-world product and technology constraints, thereby helping you to refine and document the characteristics and capabilities of a mySAP solution that can be customized and implemented for your company in support of your business objectives.
Regarding this last point, mySAP.com experts can be enlisted from many places. I suggest creating a focus team of pre-sales consultants from SAP AG itself, from a Big 4 or other capable implementation partner, and from an enterprise hardware and services partner. In this way, most of the SAP Solution Stack is represented while still minimizing the number of players.
After the vision is initially captured, disseminate it in draft form so as to begin a review process of sorts—share it with stakeholders, like senior members of the business groups who will use the solution in their day-to-day dealings, the customer-facing groups who will be positioned to better serve your customers, and the Information Technology professionals who will be tasked with supporting the solution. Formally gather and document all of this feedback, so as to better revise and refine your solution vision. To this end, I recommend updating the Solutions Characteristics Matrix first discussed in Chapter 2. Ensure that senior and executive-level management concur with the vision as it evolves, and that buy-in is achieved at all levels of your organization. Only after all of this is accomplished can the real work of planning how to actually “get there” commence.
Impact on the Business
As the business groups begin sharing their thoughts and insight regarding the solution vision, keep in mind the following:
Business processes will almost certainly have changed with the introduction of your new mySAP system, typically reflecting tighter integration and best practices.
Therefore, employee roles will change, and jobs may potentially be at stake.
Finally, the tools and interfaces used by each employee in the normal course of their job will change.
Back to the solution review process—as different folks inevitably demonstrate resistance to the project, consider the points in the preceding list, especially whether their jobs are impacted and to what degree. And just as importantly, consider each individual’s personal resistance to change. These two factors represent the key rationale behind exposing only senior members of the different business and functional groups to the new solution vision. With your senior and loyal employees on board and embracing potential changes as their own, you will be positioned as best you can against pockets of resistance lower in the organization.
Technology Perspective
Before specific software packages and hardware components are purchased, or services contracts are signed, a company must come to grips with its technology perspective, which is simply how it views its investment in information technology resources. Why? Because this shapes the architecture, or the very foundation, of a computing solution. Some companies look at IT spending from a long-term perspective, and try to purchase assets with a useful life of perhaps many years. Other companies subscribe to the belief that regular hardware and software refreshes will provide a competitive advantage or a performance advantage over time. Still others seek to stay on one side of the spectrum or the other, investing conservatively in time-proven solution stack components, or on the other hand investing in the latest and greatest high-availability and performance offerings. And finally, others prefer to outsource technology and its requisite support structure. I like to understand how a company thinks in this regard before attempting to architect a mySAP hardware and software solution; it is important for everyone to understand how risk tends to increase as investments in new technology increase, too, promising greater potential reward in exchange. This is illustrated in Figure 3.2 and detailed in the following different technology perspectives:
Conservative— As the least risky of all approaches, a company that has a conservative technology perspective places availability above all else. They seek mature technology, mature practices, and tried-and-true solutions that work, day in and day out. What they potentially sacrifice, then (though in their eyes this is not a sacrifice at all), is anything new—new approaches to accessing their system, new methods of improving availability or manageability, new solution architectures, and so on.
Mainstream— Like their conservative brethren, these companies prefer established platforms and products to newer ones. However, the key word here is “company”—they want to have a lot of company when it comes to how they solve their business problems through the use of IT resources. Mainstream companies want to be able to point to a slew of other companies and feel confident that they are not alone, that most of the industry is doing things in a manner similar to theirs.
Close follower— My favorite companies to work with tend to be close followers. They seem to leverage their IT investments in proven technology, but with exceptions. That is, although maximizing uptime always remains central, close followers are unafraid to try a few new things to gain a competitive advantage or otherwise position themselves better for the future. Therefore, they take an occasional calculated risk and invest in new products, new technologies, and new approaches.
Leading edge— This is the riskiest of all approaches, hence the more popular label “bleeding edge” assigned to this technology perspective. A leading-edge approach places more value on competitive positioning than anything else—it’s all about getting a jump on the competition in terms of minimizing cost, reducing downtime (through recent technology advances), increasing response times of customer-driven business transactions, maximizing accessibility (for example, through Internet-based vendor/partner access to your order-status system), and so on. Therefore, a leading-edge company must be prepared to spend much more time managing change, as they tend to introduce new products and approaches without the benefit of a “history.” In fact, because of this, leading-edge companies are the same ones that tend to find and work through technology problems first.
Figure 3.2. These four key technology perspectives illustrate how greater risks are related to potential reward as well as increased downtime.
When your technology perspective is clear, we can start looking at individual solution components and how all this fits together to create a custom system landscape for each particular solution. Note that I did not include outsourcing in the preceding list—the topic of outsourcing as a technology perspective is covered in the last section of this chapter.
Considering mySAP Components to Be Implemented
As the different business requirements are hammered out and in turn mapped to the solution vision, inevitably a discussion around various mySAP offerings emerges. Take care to distinguish between current mySAP component capabilities, and new features that will soon be released in new versions of a particular mySAP solution. Over the last few years, SAP has aggressively released new versions of current mySAP components, re-badged existing components and technologies, and added quite a few new components. So as you begin discussing specific solutions like Advanced Planner and Optimizer, SRM E-Procurement, or Enterprise Portal and the SAP Exchange Infrastructure, it is very important to bring in an expert versed in both the solution’s current capabilities and shortcomings, and what lies ahead on the road map.
Considering SAP System Landscape Requirements
As with the mySAP components to be implemented, it’s also important to determine the SAP system landscape requirements necessary to achieve your solution vision:
Do you need a formal training system for end users?
What about your IT staff—will a Technical Sandbox be required to help them gain a certain comfort level with new technology?
Will your functional and development/programming team need a Business Sandbox with which to learn and test?
Will a dedicated load-testing system need to be maintained that is identical to the Production system?
All these questions must be answered soon. This is why figuring out details related to your SAP system landscape plays such a big part in this chapter. In essence, though, evaluating the following will help you answer SAP landscape-specific questions as we move forward:
The relative strength or weakness of an organization often determines whether an SAP system landscape component is warranted. For example, a “weak” IT team—a team uneducated or unfamiliar with a particular technology platform—will benefit greatly from a Technical Sandbox. Similarly, a development team less than familiar with a unique mySAP component/development tool combination will require a Business Sandbox.
High availability drives much of the SAP system landscape design, too. The original “SAP 3-System Landscape” discussed in many books and articles over the years evolved out of the need for improved availability, for instance. But your particular needs may drive the creation of a more robust architecture where additional testing is possible.
The ability to recover quickly from a disaster drives the creation of a Disaster Recovery system. The term “quickly” is relative of course, but a backup tape–based restore performed on a newly installed hardware platform usually represents a worst-case baseline.
If performance is critical, adding a Staging system to a Development/Test/Production landscape can provide the resources necessary for load-testing or stress-testing changes prior to implementing them in Production (or prior to a change management package or “wave” being promoted to Production).
If the idea of simplification is important to you, there are strategies and approaches designed to do just that—simplify your SAP system landscape.
Other factors like critical security concerns, the ability to manage a particular solution, and so on will drive the adoption of incremental systems, too. All these factors and characteristics are discussed in detail in the next section.