Hershey’s overall goal wasn’t just to update their current technologies, it was also to optimize their current supply chain, reduce costs and tighten their operations through the implementation of SAP.  It was a noble set of goals, and often required of almost any company in today’s corporate landscape.  However, after three years of updating hardware and implementing SAP, their go-live phase was considered a complete and total failure.  $100 million in sales were lost in October 1999; their stock price dropped by 35 percent, and nearly the entire operations of the company was behind schedule (Bill, 2000).  This was not the goal of a three year, $112 million project.

How did this happen?  Could it all have been avoided?  The answer to both of these questions is not as simple as “yes” or “no”.  However, there is no debating the fact that at some point, Hershey was going to have to enter the 21st century and update their legacy systems.

SAP has become a necessary evil for any organization that wishes to survive in today’s cutthroat marketplace.  Simple decisions such as when and how to replenish safety stock or shipping standard quantities to customers on the first of the month need to be made automatically without any room for human intervention or error.  SAP implementation can save a company millions in optimizing their logistics and synergizing individual functional ‘silos’ within a company.  However, in order to get to that point, all companies have to implement the software to begin with, and that is where problems such as Hershey’s typically occur.  Pretty much any type of implementation can have disastrous and unintended consequences if not successful.  Each module of SAP is interconnected with many other facets of a company, such that if one small thing goes wrong in an area most people neglected to consider, then that small mistake could cause far-reaching consequences across the entire company.  This goes for even small “bolt-on” implementations to existing SAP systems.

This is an issue which corporations must face if they want to remain competitive, so it is important that as time goes on, the best methods of implementing are acknowledged and respected as standard business practices.  Even though SAP has been commonplace for many decades now, companies still run afoul by neglecting basic elements that should be expected out of any implementation, no matter how small they are.

As someone who works for an SAP consulting firm, I have witnessed companies that understood the fragility of how their software affects the company.  These organizations often thrive on optimizing their logistics systems and are always looking for a way to get a leg up on the competition.  I have also worked with organizations that have dreaded any type of change to their organization.  These companies were often toxic environments which suffered from very poor top-down leadership.  When all the stakes are considered, the true importance of an SAP implementation can mean the difference between a business staying open and closing their doors for good, potentially putting hundreds of good people out of work.

Management Information Systems have become the heart of any business operation, and as time goes on, will become even more important within the corporate landscape.  SAP implementation is one of the most important, make-or-break steps in a company’s lifespan in the 21st century.  My career has placed me in the center of these situations and there are very clear things that anyone at any level of a company can do to help their company succeed or fail between the moments when it is decided to implement new technologies and when they go-live.  The goal of this blog posting is to analyze what those key actions are and give clear recommendations for any company which implements SAP in the future.

One of the primary mistakes many organizations make is a reluctance to fully understand the importance of their software on the organization as a whole.  I have worked for managers and executives who feel their company’s software is something which “stands in the way” between them and “making money”.  Yes, these were words once given to me by a high-ranking official of a global manufacturer of carbide parts.  By devaluing a tool which can enable a company to meet and exceed their financial goals only inhibits the broader mission of the organization.

FoxMeyer Drug was a $5 billion dollar subsidiary of pharmaceutical company FoxMeyer Health, which had very complex supply chains due to the variable nature of their field and product requirements.  A decision was made in the early 90’s to implement SAP as a solution to their logistic woes.  On paper, it seemed like a dream come true.  Inventory fluctuations would be kept to a minimum, transactions would be monitored in real time, and their order process would be automated and simple.    FoxMeyer has an obligation to iron out their supply chain issues and trim the fat in order to remain competitive, so the decision to utilize SAP was a very easy one to make.

FoxMeyer made the choice of adopting a “Big Bang” approach to implementing the complex software (Bulkeley, 1996).  A “Big Bang” approach is when a company has all segments of their operations move into their new system at the same time.  It’s described as an “instant changeover” and is often compared to rushing an entire football team through a single small door in a matter of seconds.  For smaller companies, this can be a useful strategy.  For larger ones, it’s more like fitting an entire parade through a small door in a matter of milliseconds, it’s ill-advised and simply not that great of an idea, despite the need to go-live as quickly as possible.

FoxMeyer faced many more problems than just a their choice of implementation strategy.  Warehouse workers who were not properly educated on the benefits of the project felt that their jobs were in danger of being replaced by machines.  A poor initial transition to the SAP software in the first warehouse did not help boost employee morale either.  This led to a massive influx of disgruntled employees and an eventual loss of $34 million worth of inventory (Scott, 2000).  This could have easily been prevented by greater communication between the warehouse workers and the executives of the company as to what the ultimate goal of the implementation was, as well as how SAP could greatly benefit the company and the workers.  An overall negative view of the SAP implementation project can easily derail the process due to an end-user’s unwillingness to accept and learn how the software can benefit their jobs and ultimately make their lives easier.

Eventually, FoxMeyer Drug’s implementation had gone well over-time and budget, resulting in over $100 million dollars sunk into a project which was beginning to cost the company hundreds of millions annually.  Eventually, despite annual revenue of over $5.5 billion, the division of FoxMeyer Health filed for chapter 11 bankruptcy in 1996, only 3 years after it began its implementation of SAP (Unknown, 1996).  While there were many reasons for the failure of the implementation, in hindsight it remains very clear the root cause of the bankruptcy was the implementation itself, and the financial hurdles that were left for the company in its wake.

One of the key elements of SAP is its ability to interconnect all segments of a company.  This means that each individual transaction, accounting document and shipment can affect the financial position as they happen, keeping the system up-to-date and becoming a one-stop-shop for anything that needs to be known in order to make a decision.  Mexican-based oil company Pemex has a “control room” deep in their corporate headquarters which monitors their entire operations in real time (Chavez, 2008).  What is essentially a room filled with charts and graphs connected directly to SAP allows executives to see the effect millions of individual transactions have on the company as they happen.  So when someone fills their tank with Pemex at a gas station somewhere in the world, you can actually see the effect in real time with their custom-made gauges on display within the “control room”.  It is this type of real-time information which allows decision-makers at the top of a company to make the most accurate and informed decisions possible in a marketplace where everyone wants to be at several steps ahead of everyone else.
This is a double-edged sword however; because having all components of an organization interconnected through SAP also means that any small change within that software can dramatically shift all of the information which is flowing through a company at any given time.  If a configuration is not setup correctly, or a default setting was not considered during implementation, a small adjustment in quantities or pricing could result in an error multiplied by the number of transactions in the system, which could manifest itself in the form of a high dollar value error.  The larger the company, the more severe a minor error in a sensitive spot can be.

In Part 2: I’ll analyze individual SAP implementation failures and their subsequent fallout’s.

Can’t wait to read the rest of the Mind the Gap series? Submit your information below to receive the entire series today!

Some SAP Retail customers need an alternative to the SAP POS module or other outside POS interface.  Lean Order Management (LOM) is a real alternative that runs order fulfillment processes directly in SAP through a portal interface.  A number of enhancements can be made to the base LOM product to make it a fully functional Retail POS.  This is particularly beneficial to companies that need real time, up to date information.  LOM can be successfully deployed across a large end user base as a Retail POS.

What Will Be Highlighted:

• In this session you will learn how other retailers have integrated and leveraged LOM across hundreds of stores with minimal end user training
• Discussion will include the necessary enhancements needed to simplify the order process (sales, tender, refunds and returns), reducing associate / customer POS interaction and allowing end users to focus on meeting customer needs and enhancing the customer in store experience.

Date:  TBD
Time:  TBD
Duration: 30 Minutes
Speaker: TBD

How do you convert these external customer numbers into your internal SAP customer numbers?

Some may hard code these conversions into their EDI maps.  This approach can be very high maintenance as customers can add new ship-to locations or reorganize their internal numbers which would require changes to your maps.

Others may set up a cross reference table within their EDI translation table to perform the conversion.  This works well at times, but then you are at the mercy of your EDI group to update the table with any new additions or changes to existing entries.

I find the best way to perform this conversion is within your SAP system.  Mainly because SAP has given you a standard utility to perform the conversion.  All you need to do is populate a few fields of the incoming IDOC and populate the EDPAR table using transaction VOE4 with the internal and external customer numbers.  The Function Module used to process the IDOC takes care of the rest.  SAP uses the Sender Partner Number of the IDOC Control record along with the PARVW and LIFNR elements from the E1EDKA1 segment to look up the correct entry in the EDPAR table.  In your EDI maps you would populate the PARVW element with the partner function code for the external customer number (AG = Sold-To, WE = Ship-To) and populate the LIFNR field with the external customer number received in the EDI file from that partner.  All other fields would remain blank in the E1EDKA1 segment.

Sender Information Partner Number from the Control Record:

E1EDKA1 Segment for the Sold-To Partner (AG):

E1EDKA1 Segment for the Ship-To Partner (WE):

Use transaction VOE4 to populate the EDPAR table.  You enter the value from the Sender Partner Number in the IDOC control record in the Customer field, the function code for the partner in the Ext. Function field.  Note: The Ext. Function field will not be the same as the Partner Function (PARVW) element of the IDOC.  (AG in IDOC = SP on VOE4, WE = SH).  The External Partner is the number received in the EDI data from the customer which is also the number in the LIFNR element of the IDOC.  Int. no is the SAP customer number associated with the External number.

VOE4 transaction with required entries for the Sold-To and Ship-To for IDOC information above:

Using the EDPAR table for customer conversion allows this function to remain in control of those responsible for customer accounts.  Users can be trained to use the VOE4 transaction to update the EDPAR table so when new ship-to or sold-to numbers need to be added they can be done in a timely matter and not rely on other departments.  It also takes this responsibility away from the EDI group so they don’t have to maintain maps or tables for this function.

This function can be used for other incoming IDOCs as well.  You will need to check the Function Modules used to process incoming IDOCs to determine if EDPAR can be used for customer number conversion and on which IDOC segment you would send the external number.

Outbound IDOCs can use either the EDPAR table or the PUMA table to cross reference external customer numbers.  Again, it depends on the IDOC type.  I will cover this topic in a separate blog.

For the element that’s text cannot be hardcoded or the element that’s visibility needs to change during runtime, the context needs to be used. The data that is seen on the screen is not stored within the web browser itself. The Web Dynpro application makes calls to the server to retrieve data to be displayed. This is where the context comes into play. The context is the memory on the server that stores data for the Web Dynpro application. When setup correctly a context can hold tables, structures or single element variables. Here is an example of how to build a context and then make method calls to read or set the context.

Select the ‘Context’ tab. Right click on the context node and select ‘Create’ -> ‘Node’ and fill out the fields according to the picture below.

Right click on the BUTTON_PROPERTIES node and select ‘Create’ -> ‘Attribute.’

Now we have created an attribute in the context that will hold a string value. By the names I have given to the node and the attribute you can guess that this node will hold any attributes related to the button we created. The attribute that we created will be used to hold text value of the button.

Now that the context attribute has been created, let’s fill it with a value. Go back to the button properties under the ‘Layout’ tab and find the ‘onAction’ properties under ‘Events.’ Click the create button, it looks like a white piece of paper with the top right edge folded down, and fill in the fields as below.

Double click on the name of the new action we just created, SHOW_TEXT and this will take you to the methods tab. Here we are going to use the Web Dynpro Code Wizard to set the value of the attribute.
Click on the Web Dynpro Code Wizard icon (or Ctrl +F7), select ‘Read’, click and select the attribute that was created, TEXT. (Illustrated Below)

Now repeat the same steps starting with the Web Dynpro Code Wizard except this time select ‘Set’ instead of ‘Read.’ Each time the Web Dynpro Code Wizard is used DATA variables are created.

Note: If there are multiple attributes within a node, all of the attributes can be read or set at once by selecting the node.

After using the Web Dynpro Code Wizard the second time we now have two copies of the data variables that will not compile. Select the second set and delete them and in place put the following code:

Now if the application was tested the value of the attribute TEXT would be changed  between ‘Hide Text’ and ‘Show Text’ every time the button is pushed.

That is the rundown of how to build, read and set the context’s nodes and attributes. Now the context needs to be linked or ‘bound’ to the UI elements. Go back to the Layout tab and select the button. Under the properties find the ‘Text’ property. Click the yellow box to the right of the property and select the attribute to create the binding .

Binding

Binding is linking the data in the context to the UI elements. Here we have created an attribute that holds text. The ‘Text’ property of the button is set to the value within that property. Activate the Web Dynpro Component, create an application and test it.

For a little extra practice, add a TextView by dragging and dropping into the layout or right clicking on ROOTUIELEMENTCONTAINER and selecting ‘Insert Element.’ In the properties section set the Text value to ‘Now you see me!’ Create another node and attribute for the TextView by going to the ‘Context’ tab and right clicking on the ‘Context’ node and selecting ‘Create’ -> ‘Node’. Then create the attribute with the properties below.

Go to the ‘Methods’ tab and go into the method we was worked on earlier, ONACTIONSHOW_TEXT. Place the cursor after the ‘if’ statement that was put in, approximately line 33. Use the code wizard to set the new context we made. Then cut and pasted the DATA declarations just created and move them up to the top of the code. Then edit the ‘if’ statement to look like this:

Return to the ‘Layout’ tab, select the TextView and set the ‘Visible’ property to the new attribute. Activate the Web Dynpro Component and test the application.

At DataXstream, we create tailored solutions for SAP Retail that give retailers tools which allow them to capitalize on the retail revolution and achieve success in today’s business environment.  Our dedicated team of Retail-focused SAP experts, with specialties ranging from technical and functional implementation to custom configuration and strategic project management, enables our customers to realize the full potential of SAP Retail’s highly flexible, configurable, and powerful solution toolset.  Whether you are a food, hardline, or softline retailer, Dataxstream can help you achieve operational and supply chain excellence with your SAP Retail system.

Let’s look at how this process works.  Let’s say we have created an invoice document in SAP.  In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15.  If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot.  The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to).  The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to).  The External Partner field will contain the external partner number that the customer is expecting on the EDI file.  And the Int. no. field will contain the SAP partner number (Same as the Customer field).

After we have set up the Partner Profile (WE20) for the INVOIC for this customer we can produce the output through transaction VF02 to create the IDOC.  The INVOIC02 IDOC will display the Sold-to and the Bill-to partners at the Header level in the E1EDKA1 segments, but because we could have multiple Ship-tos on an invoice the Ship-to partner(s) are located at the Item level in the E1EDPA1 segments.  In both segments, the external partner numbers will be populated in the LIFNR element.  The segments for the three partners are displayed below:

As you have probably noticed, the Partner Functions on the IDOCs do not match the Partner Functions in the EDPAR table.  Those would translate as follows: SP in EDPAR = AG in the IDOC, SH = WE, BP = RE.  As you can see the LIFNR field is populated with the values in the External Partner field of the EDPAR table.  These values can now be used in the EDI mapping tool to send the value to the customer.

This is a useful tool as new partners can be added easily using the VOE4 table by a customer service representative.  It also keeps the cross reference within SAP so that the EDI group does not have to build their own functionality to convert the partner numbers and maintain it as new customers are added or locations are changed.

This table can be used for other partner types and other outbound IDOCs.  You would need to check the function module that processes the output to see if it uses the EDPAR table and for which partners.  Another internal SAP table that is used for partner cross reference is the PUMA table.  This is used when creating DELVRY and SHPMNT IDOCs whose function modules do not use the EDPAR utility.  The use of the PUMA table will be discussed in a separate blog.

The coaches told me it looked like I was skiing conservatively down the icy slope in Kranska Gora, Slovenia and I am confused.  Although I watched video that confirms I was hooking the end of each of my turns and thus slowing me down at every gate, I wonder why skiing slowly takes so much work and when I am skiing my best it feels so effortless?

Sometimes I want to sleep in and skip the risk of failure but deep down I know that then I would also miss an opportunity to succeed!   The next step towards finding my speed and my confidence are the Noram cups in Vail, Colorado.  I hope that there are more good results in my skiing future but success can be defined differently depending on whom you ask.  Until then I am going to keep watching my Disney and Pixar films because they always have a happy endings and help me remember to BELIEVE!

Highlights from my January trip to Europe include rodeling and a fondue dinner!  Below are some nice pictures from my three week adventure over seas……….

The women's world cup tech team training slalom at our new European home base, Solden, AUT (left to right: Resi, Me, Sarah, Hailey, Lindsay our physical therapist and Mikaela)

Powder skiing! Solden, AUT

Hailey Duke showing us how it is done!

FIS giant slalom in Oberjoch, GER. More new snow!

Some of the festivities at our world cup race in Kranska Gora, SLO

Saying goodbye to our awesome physical therapist, Lindsey! ;-( Until next year lady!

In continuing my series of lessons learned with SAP Retail I would like to cover the topic of Client Resources and Planning. Again, in general many of these lesson I have learned could be applied to any project and I can easily draw parallels from other SAP industry solution implementations that I have led in the past. I will do my best to highlight where I think there are specific retail differences.

There Are Never Enough Client Resources

This is the case on almost any large-scale project, not just SAP projects. It impacts smaller organizations and it impacts retail businesses more because they tend to run leaner IT organizations. So you might be saying to yourself, “big deal; what project not funded by the government doesn’t have enough resources?” This one point however might be the most important one I make in this series.

Think about it. In a new SAP Retail implementation you are going to completely replace the core of your IT business systems. This typically impacts all aspects of your business; Finance, Store Operations, Merchandising, and Warehousing. It typically reaches outside your organization and impacts your Business Partners as well. So how do you fix resource problems? As a leader, and I am specifically talking to the CEO (or your organization’s equivalent) here, because he/she is the only one that can make things happen on the resource front. CEO’s, you need to engage the entire business in this process in a meaningful and organized way from the project’s inception and kick-off all the way to go-live and post go-live support.

I know from experience that this kind of ideal C-suite-to-IT alignment does not always occur. My uncle was the president of a division of Honeywell that implemented SAP. I can remember talking with him about his project and being a little frustrated with him. He knew the project was important and impactful but from the language he used I could tell that he did not grasp the significance of the undertaking that an SAP implementation demands and that more overall focus and dedication from the organization as a whole would reduce the time required for the business to successfully adapt to the new system.

Don’t make this mistake in your implementation; engage the best of the best in your organization on the project, and engage the entire organization in meaningful ways throughout the entire project. The more exposure and input people have doing the implementation the easier the transition will be. Always remember, there is no such thing as “cutting corners” in SAP implementations (or any SAP project for that matter). You always end up getting as much from your SAP system as you put into it. Settling for adequate resources at bargain prices will do two things: cut immediate resource overhead costs and produce an adequate SAP system for your business.

Client Management Expectations For Their Internal SAP Resources Are Always Unrealistic

OK, so this is not specific to Retail; it is a recurring theme from all my SAP project exposure.

• First point: unless you have implemented SAP before you and your resources will automatically underestimate what it is going to take to get the job done.
• Second: don’t expect seasoned IT resources to work an SAP implementation and come out of it completely capable of supporting the system on their own after go live. One out of ten will be able to fly solo after go live,  the rest will need assistance for sometime in the future. (By the way, the ones that fly solo need to be rewarded significantly, if not they will be consultants within 12 months)
• Third: look at what you are asking of your resources. If you have them working on business requirements, functional design, test planning, test script creation, test execution, training, etc., do they really have the capacity to do any of these activities simultaneously while maintaining high-quality output? Engage more of the business and spread out the load. After all, implementing SAP is a business commitment, not an IT department commitment. I will make recommendations in other sections on where you can engage more of the business.

There Is Never Enough Time For Knowledge Transfer

Knowledge Transfer (KT) is an activity that is always held high at the beginning of the project but it is the first part of the plan and budget to get absorbed when things don’t go as planned and it is never replaced. In addition, it is never given proper consideration, planning, and execution like any other phase of the project. Failing in KT can potentially squander all the effort and investment you’ve put into an SAP project; new technology has ZERO value if your business users are not proficient at using the system. You should treat knowledge transfer planning and execution just like testing, with specific goals, topics identified and capacity planned. It should also be spread out thoughtfully across the duration of the project. Expectations / level of KT expected also needs to be clearly communicated to both the consulting team and internal team. You need to have realistic expectations here. At the end of KT, your internal resources (especially if new to SAP) will not be able to do what your consulting team can. Knowledge transfer is often approached using the “fire hose” technique. SPOILER: it does not work.

Fire Hose Technique -  Tasking several of your senior SAP consultants to simultaneously knowledge transfer to the same beginner SAP client resource via a two week brain-dump.

There are very few people that can effectively learn this way. Genuine knowledge transfer can only truly be achieved through doing, not watching or listening. Engagement and participation throughout the entire project lifespan will lead to knowledge transfer organically. The most effective way to execute knowledge transfer is to plan a PPS (Post Production Support) phase that keeps the consulting team engaged – some full time, some part time, and some as needed. This will enable the transferring responsibility and knowledge overtime. It is important to understand you will need to push the internal team here, you want the consulting team as a safety net not a crutch.

Client Resources Can Cause Delays Too

OK, now it’s time for me to call out all my clients from the past. This is more of a universal lesson learned but it especially applies to SAP Retail projects. Consultants and consulting teams are not always responsible for project delays. It is our job as consultants in most cases to take the heat and blame whenever deliverable dates are missed; that is part of our job function and it comes with the territory. What sort of things am I referring to? Information needed by the project team needs to flow quickly, and there is often information and tasks that extend outside of the identified SAP project team. It is important that from the top down those tasks are given priority and accomplished with a sense of urgency from Day 1. Oftentimes, teams have to push ahead making assumptions and then have to backtrack to fix wrong assumptions once they receive the information from the business. Good consulting teams never sit around twiddling their thumbs while waiting to receive all the information needed; they assume leadership and use good judgement to help their client be successful.

It is also important for SAP project leadership to monitor for “Analysis Paralysis”. While some consultants can be susceptible to this it is more often the client resources that come down with this serious condition. “Analysis Paralysis” is the most common reason projects get delayed. If you have unlimited budget then go ahead and try and think of everything. Otherwise you need to quickly review the information you do have, pour on some assumptions, and move forward. You will learn more as you progress through the project and can always go back and refine those critical things that you have missed. Prototyping and pilots give you more opportunity to move forward more quickly with an approach that can be refined as you get smarter.

One last point on client resources delaying projects: do not put procrastinators on your SAP Project team. You need to put your resources that hit the ground running and do their best to stay ahead. The average SAP project costs 16 million dollars. This is a pretty significant capital investment for any company. All it takes is one procrastinator in one area of the project to slow down the efficiency of the entire team.

So I got derailed a bit at the beginning of the week so I am behind schedule on my topic list.  I will do my best to cover planning this evening and post sometime tomorrow to keep on track.

Be on the lookout for my next post, which will Lessons Learned for the Planning phase of an SAP Retail project. The remaining schedule is as follows:

Here is an outline of my future lessons learned post topics:

• Week 3
• Design - If It Is Hard or Complex You Most Likely Are Taking The Wrong Approach

• Week 4
• Execution
• Basis - Size Does Matter
• Configuration - Prototype And Prove Out Approach Before You Commit To Process
• Development - RICEFW Can Not Be Developed In Silo’s

•  Week 5
• Testing - Testing Design Is More Important Than Solution Design
• Go-live Planning & Execution - Have An Implementation Methodology That Tests Your Go-live Plan As You Go
• Go-live - Big Bang Not A Good Idea For  An SAP Retail Implementation (Without A Pilot)

• Week 6
• Post Production Support - Figure This Out Prior To Go-live

To date, I’d have to say that of the business decision makers I meet, only about 30 percent of them know what virtualization is.  Now on the flip side, of the people who are actively down in the trenches managing systems on a day to day basis, nearly 75% of them have either used some method of virtualization or heard of it.  My question is, why is there such a disparity in knowledge of something that can be so beneficial to an organization between these two groups of people?

Well that’s what this post is about, educating decision makers about the numerous business benefits that virtualization solutions provide.

 

Virtualization History Lesson

Virtualization as noun, refers to technologies designed to provide a layer of abstraction between computer hardware systems and the software running on them. By providing a logical view of computing resources, rather than a physical view, virtualization solutions make it possible to do a couple of very useful things: They can allow you, essentially, to trick your operating systems into thinking that a group of servers is a single pool of computing resources. And they can allow you to run multiple operating system installations simultaneously on a single machine, thereby greatly increasing the utilization of any one piece of hardware.

Virtualization has it’s origins in partitioning, which divides a single physical server into multiple logical servers. Once the physical server is divided, each logical server can run an operating system and applications independently. In the 90s, virtualization was used primarily to re-create end-user environments on a single piece of mainframe hardware. If you were an IT administrator and you wanted to roll out new software, but you wanted see how it would work on a Windows NT or a Linux machine, you used virtualization technologies to create the various user environments.

But with the advent of the x86 architecture and inexpensive PCs, virtualization faded and seemed to be little more than a fad of the mainframe era. It’s fair to credit the recent rebirth of virtualization on the x86 architecture to the founders of the current market leader, VMware. However VMware couldn’t have done it alone, and I often credit Moore’s Law in helping computing power reach a point where virtualization was once again a viable solution in the enterprise.

That’s great, but how exactly can virtualization help me and my business?

Let’s take a look at a few different benefits that a business will realize by pursuing virtualization solutions for their next project.

Reduce datacenter costs by reducing your physical infrastructure footprint: This is probably the point most CIO’s and decision makers are aware of, fewer servers and related IT hardware means reduced real estate and reduced power and cooling requirements.  Getting ready to perform an upgrade? Current hardware infrastructure coming up for refresh?  These are ideal times to deploy a virtualized infrastructure with VMware and SAP.

Get more out of your existing resources: With VMware, you can begin to take advantage of advancements in computing technology by ensuring we’re using what you paid for!  On average, we see single application servers utilization hover around 15% – 20% of it’s potential capacity.  You purchased the hardware, you should be taking full advantage of it! With virtualization, your IT department pools common infrastructure resources and can finally break away from the age-old “one application to one server” model with server consolidation.

Increase availability of hardware and applications for improved business continuity: For those who have ever gone through the trouble of creating a 100+ page run-sheet of requirements for a disaster recovery solution, this is for you.  In addition to simplifying the execution of a disaster recovery event, by utilizing VMware as your virtualization solution,  you now have the ability to do audits on your disaster recovery plan in production without the concern of service downtime!

Gain operational flexibility: Going beyond the cost savings justification, with SAP running on VMware, you now have the ability to dynamically scale your application’s performance needs in real time to meet increased demand.  Have an upcoming “fire-sale” on that new wiz-bang thing everyone’s talking about? Now you can respond to market changes with dynamic resource management, faster server provisioning and improved desktop and application deployment.

Help your IT staff help you: VMware’s virtualization monitoring and management tools allow your IT staff to realize increased productivity when managing your virtual infrastructure by utilizing VMware’s robust set of utilities.  IT administrators can provision new resources in minutes instead of hours, freeing them to focus on more important tasks related to your SAP infrastructure.  Snapshots, Disaster Recovery, general system maintenance, are all handled through common management utilities that any resource can learn with ease.

I want it all! Where do I get started?

The first step of any virtualization project begins with a readiness assessment.  DataXstream will examine the current state of your infrastructure, determine where your business is growing, and accurately provide you with a design which focuses not only on cost savings, but also positions your company to be more flexible for future planned activities such as upgrades, increased demand, etc.  By taking advantage of server virtualization you can easily improve the efficiency of your SAP infrastructure as well as seeing immediate cost benefits by lowering your cost of ownership, and increasing the productivity of your IT staff.  All while positioning yourself to be more elastic in order to meet the ever changing landscape of business, there has never been a better time to explore the benefits of virtualization.

Stay tuned because in a later post, I’ll be examining the Technical Benefits of SAP virtualization, and why if you’re not exploring virtualization you’re already “behind the curve”.

DataXstream will be present at Retail’s Big Show later this month (Jan 15-17) to talk all things SAP Retail. Will you be in attendance? Send us a message below to connect with us in New York later this month.

DataXstream: A Proven Expert in SAP Retail

Since a great number of SAP shops exist these days, you might ask yourselves why, as a retailer, you would choose DataXstream to implement SAP for Retail for your business.  It is a good question, and we have a great answer.

First and foremost, we at DataXstream are proven experts in SAP, having worked in the SAP world for more than 15 years and having established an excellent reputation.  Simply speaking, we understand SAP extremely well.  You can absolutely trust us with any SAP project.

Secondly, we have a proven track record when it comes to the specifics of SAP for Retail. With us on your team, you can expect to implement SAP for Retail 50% faster; have all the unique configurations of the system you need to best reach your business goals, and even have your system customized to improve upon SAP’s already excellent functionality.

Thirdly, we are experts in virtualization, as well, which means we give you the unique opportunity to virtualize your SAP environment if you so choose.  Many cost-savings and other benefits (including flexibility and increased responsiveness to business growth) can result from a virtualized environment.  For more details on the benefits of virtualization, read here.