During the last few months, on a recurrent fashion basis, there has been a topic surfacing every now and then as it hurts our business: planned downtimes.

This said, all global companies, working round the clock, with a presence on all continents, all working on a single global system/infrastructure will face the same problem.

So how do you manage the planned maintenances which, obviously, will impact the daily activities of your workmates, as they do not understand why, in 2010, you still have to stop the systems to carry a maintenance.

Even today, IT/IS is seen as a cost center, barely, as a profit center. In this case, this becomes even more true as it impacts the productivity of the enterprise. Still you need to ensure the consistency of your systems, of your data, do some housekeeping in order to ensure proper performance and sometimes you’ll even have to apply some patches.

So, in the complex landscape that are so typical to the SAP world, how would you manage a proper lifecycle management of your applications and infrastructure without disturbing the business ?

1. Communication

People are able to organize their activities around a downtime, provided they know when it will happen, with enough lead time. A month in advance would be barely enough to allow the proper organization of everyone around the globe. You have to take into account that this might not just affect your colleagues but also all your business partners (customers and suppliers).

You should look forward to publishing a quarterly/yearly calendar with all major activities. Make it online, accessible to everyone so anyone, who has doubts about the planning, can refer to it.

You may also use some marketing and explain how the major operations (e.g: upgrades, support packages) will benefit to their activities.

During the maintenance, you may provide a status to the users to let them know which applications are available. Social Media has great tools for that (blogs, micro-blogging, status pages).

And in order to avoid anyone forgetting there’s a downtime next week, do not hesitate to send a friendly reminder a month and/or a week before.

For all your communications, you will need to target the right audience and have your direct network transmit the information to their teams.

2. Process

Efficient management of planned maintenances is barely a question of technology. Of course it helps, and we will discuss it later, but it only comes as a support.

In order to enhance your maintenances and minimize their length, have a detailed plan of the activities, ensuring that all the dependencies are fulfilled, and that the required skills are available.

After the downtime, review the activities and draft your lessons learned: What should be avoided next time. Use this in your plans for the future.

Periodically, review the last months maintenances. Review the planning and see what can be improved: bundling the activities differently, testing more carefully some items in the test environments before applying them into your production. Among the tasks that have been planned, see which could be planned online with limited impact on the systems/users.

Make sure you manage core and sensitive components differently from the others. While a longer downtime of your intranet might be acceptable, it would harldy be the case of your ERP system. In order to manage this, for each task and system you need to define the criticity and the priority. You will end up building a matrix defining what should be done first and what can be postponed.

Define a rollback plan. Worst thing is to be taken aback. For each task, make sure you identify the risks and your rollback plan. The latter should be planned the same way you would do for any other task (priority, duration, dependencies, resources).

3. Technology

Technology can help you lots in limiting the impact of your maintenance on your business, and you should leverage it.

High availability will be one of your toys to pet. Make use of it. You have invested lots for your DRP plan. But HA can help you otherwise. If you need to carry a maintenance on your hardware for example, you might just switch to your mirror infrastructure and bring the applications back there while you’re working on your primary site.

This is also a good opportunity to test your HA infrastructure and potentially your DRP process.

Virtualization has matured over the years and is now able to provide a high degree of flexibility.It creates a greater abstraction between the different layers. Adaptive computing lets you rebalance your resources between components. As a preparation task for your maintenance, you might look forward making temporary changes in your configuration to avoid a complete disruption of the service. Keep in mind that these changes (and reverting them) need to be supported by a detailed documentation.

Monitoring: Planned downtimes are great but they need to be supported by a rationale which will help you define which activities need to be planned. A proactive monitoring of your systems should allow you not only to get the proper alerts but also to identify the trends and thus identify the key actions that need to be undertaken.

Planned maintenance could easily shift from a pure technical topic into a political one whenever it has an impact on the business. IT, in its state of art, is designed to service the business. Thus, make use of creativity and fine analysis in order to provide the best of breed service to your customers.

Most business application consultants and experts have a high emphasis in one aspect of the solution (say finance, controlling, HR, CRM), sometimes, they even go to higher focus (marketing campaigns within the CRM) but very few of them would know what happens in the next phase of the process. They usually work in a blackbox mode knowing the input they’re getting from previous phase, how to process it before serving it to the next phase.

This has worked pretty well due to the widely spread practices in the implementation of processes within monolithic solutions. These processes were also mostly fixed as companies rarely looked forward constant process innovation to keep up with the pace of competitivity. But today, the world’s changing. Processes are being executed across the solution boundaries and even across the company’s boundaries, they may be re-engineered at several phases to match the company’s strategy on the market.

If we take the computer manufacturing industry, the usual process would be “Manufacture the equipment -> ship to dealers -> Select the equipment (customer) -> Pay (customer)“. DELL has drastically changed this process, which earned them a highly competitive advantage at several levels. The process has been changed to “Select the equipment -> Pay -> Manufacture the equipment -> Ship to customer“. At this point, DELL has improved at least on two main points: exit the dealers, reducing the number of  intermediates and they don’t need fully manufactured stocked equipment. Basically computers are stocked in warehouses in a pre-assembled state. Assembling might even be transfered (outsourced) to Supply Chain providers. At this point, they’re having a direct contact with the customer, tightening the relationship, and they’re increasing their profitability (fixed costs reduction).

For solution experts, this has a major impact on the way they usually implement the process. They need to have a complete understanding of the impacts of the re-engineering on their blueprint. How they shift from a data receiver from process step 3 to a data source for step 2.

For this purpose, the experts will require to have a broader knowledge of what they are implementing, how’s their part is being integrated within a wider scope, what happens in every phase and then they should shift into a full understanding of the process end-to-end.

So if you wonder how you can update your skills ? What you should look at ?

I say, forget modules and go end-to-end process: Order to Cash or Procure to Pay. With today’s technology and solution maturity, processes tend to have tighter integration between them. They are not just merely tables and transactions, but there’s a real logic flow orchestrating each step of the process.

Coupled with the Business Process Experts/Champions/Owners, the consultants will seek into bringing a higher value to their customer/company by optimizing the execution of the process at every step with a coherent and comprehensive understanding of the impacts of each action and decision.

In an SOA approach, the isomorphism between the process and the services will lead  to create fine grained components which are then assembled altogether into composite applications. This leads to a tighter integration of components (logical point of view) as a service might as well execute operations in a project and finance systems.

While there might still be confusion among SAP practitioners on the ability to go from a modular perspective to the end-to-end perspective, this change will be driven by the market evolution and the solution architecture anyways. The idea is that rather than being an expert on 10 FI processes while you usually implement 4 of them. The skills evolution roadmap would guide you through the different stages of your process implementation within the other modules/solutions, hence fully leveraging your training and expertise on all areas.

This full fledged knowledge of the process will also provide a new empowerment that will allow experts to drive the innovation to reflect the business requirements or even anticipate them,  as this is where the real value lies.

Lately, I have been highly involved in the implementation of SAP Business Planning and Consolidation for NetWeaver at a customer. As you might know (or not), this product was until, this morning, in a Ramp Up process.

This is the first version of the port of the Oulooksoft product on the NetWeaver platform, it has introduced along, several new concepts to the solution, which are basics of a standard SAP solution.

Among the changes, SAP BPC for NW has now the transport concept which allows you to transport your customizing along the environments on your maintenance track. As the product lacked documentation on this aspect, I have decided to release a document providing an overview of the transport concepts, tools and a governance approach for managing changes in SAP BPC.

You may download the white paper from the SAP Developer Network, on the Enterprise Performance Management page.